GSLT: Design Patterns

1. GSLT: Design Patterns Lars Degerstedt Linköping university, IDA larde@ida.liu.se

2. Overview • 1st hour: Ex. of Design Patterns • the concept • Examples: • creational: Singleton and Factory. • behavioral: Objectifier and Iterator. • 2nd hour: the GoF Catalogue

3. Literature Books Design Patterns, Gamma et al, Addison Wesley,1994 Patterns in Java, Vol. 1, M Grand, 1998 Object-oriented Design and Patterns W. Pree, 1995, Addision-Wesley (Out of Print)

4. What is a Design Pattern? • Pattern: problem+solution+context. • A new level of abstraction: • not algorithmic, • not module-level, • not a system architecture. • GoF: • reuse of micro-architecture. • not a new concept - a catalogue!

5. Ex: The MVC Design Pattern Model Change of state Subscribe/notify View Controller User-event-handling

6. Window Window Window a=50% b=30% c=20% The MVC GUI Component a b c x 60 30 10 y 50 30 20 z 80 10 10 a b c

7. Features of MVC Components • Separation of model-view: • serveral views • change a view without changing the model. • Compound Views: • composition of views is easy. • Separation of view-controller: • change user-event-handling without changing the view.

8. Singleton • Ensure one (n) instance(s) of a class. • The instance should be accessible for all client of the class. • Examples of use: • Debug or configuration utilities. • Database or parser server manager. • Java.lang.Runtime - access to OS.

9. Class diagram: Singleton Singleton static Singleton() private Singleton (first: bool) operation() getDaten() if uniqueInstance == null then uniqueInstance = new Singleton (true) return uniqueInstance static uniqueInstance data

10. Pros and Cons: Singleton • Features: • improvment over global variables. • More flexible than ”class operations”. • Potential problems: • how to subclass a singleton? • threads: one singleton per thread? • Alternatives: • extension: use a registry Singleton of singletons. • pass as (compound) parameter.

11. NLP Relevance: Singleton • A singleton manager class for each module in a dialogue system. • A jungle of singletons for different data sources… • Problems when split into several processes - one singleton per process.

12. Factory • How to create ”product” objects through a generic interface. • Manufacture custom compositions, shared one-of-a-kind etc. • Avoids specifying the concrete classes of the ”products”. • Ex: different look-and-feel of widgets.

13. Factory: Class Diagram Client AbstractFactory Abstract product A createProductA() createProductB() ProdA2 ProdA1 Concrete Factory1 Concrete Factory2 Abstract product B createProductA() createProductB() createProductA() createProductB() ProdB2 ProdB1

14. Factory: Pros and Cons • Features: • isolates concrete classes: the factory creates new instances - abstract names in client code. • change of product families easy. • consistency among products: work on one product family at the time. • Adding new products is difficult: • solution: parametrisation of product name.

15. Factory: NLP Relevance • JAXP: abstract Java representations for XML documents. • General: abstract APIs for e.g. Interpretations. • GATE2: suggests to organize NLP representations in a taxonomy.

16. Objectifier • Separation of abstraction from implementation. • Subclasses cannot change during runtime. • Objectify the varying behavior. • Use when a large amount of code is conditional. • Ex: listeners in Java Swing MVC.

17. Objectifier: Class Diagram Client Objectifier getObjectifier() objectifierInterface() ConcreteObjectifier A ConcreteObjectifier B ConcreteObjectifier C objectifierInterface() objectifierInterface() obectifierInterface()

18. Objectifier: Pros and Cons • Features: • Encapsulation and customisation. • Composition instead of inheritance: increases reuse. • Stateless objectifiers can be shared. • Potential problems: • additional level of indirection. • choice of objectifier:client can be exposed to implementations issues.

19. Objectifier: NLP Relevance • Dialogue Manager: e.g. the focus algorithm. • Generation: handler for text-frames with variables. • Barge-in-handler: extraction of different barge-in strategies.

20. Iterator • Access elements of a collection sequentially. • Does not expose underlying structure. • Uses the basic pattern Objectifier. • E.g. The interface java.util.Iterator • Can be combined with Composite.

21. Iterator: Class Diagram Iterator AbstractList Client First() next() previous() (opt) hasNext() ... createIterator() count() append(Item) remove(Item) … ArrayList LinkedList LinkedListIterator ArrayListIterator

22. Iterator: Pros and Cons • Features: • supports variations in traversals • simplifies the aggregate interface • supports parallel iteration of an aggregate. • Potential problems: • changing aggregate during iteration • high-order iterative constructs: map-car?

23. Iterator: NLP Relevance • Traversal of a Dialogue tree. • Traversal of feature structures • Traversal of lexicon and grammar representations. • Traversal of Charts

24. Overview (2nd hour) • 1st hour: what are Design Patterns? • 2nd hour: the GoF Catalogue • GoF: for problem-solving • History and Frameworks • Patterns of Java Swing • The Adapter Pattern • The Observer Pattern • how to use patterns

25. GoF – ”problem-solving categories” • Jurisdiction – the related oo concept: • class: static semantics. • object: relations of peer objects. • compound: recursive object structures • Characterization - what it does: • creational: object creation. • structural: composition of entities. • behavioral: interaction and responsiblity.

26. The GoF Catalogue Characterization Jurisdiction

27. History • Object-Oriented Patterns: late 70s. • e.g. Smalltalks Model-View-Controller • OO Frameworks i general: • how handle the complexity for the user? • A Pattern Lanuage (Alexander ´77) • ’91: workshop towards an architecture handbook... • E. Gamma Ph D Thesis (´92): E++

28. OO Frameworks • Component: a static unit of deployment. Often a module. • OO Framework: partial design of a (class of) system(s): • white-box: • user must learn the code. • based on inheritance. • black-box • based on composition of components.

29. Purpose of Design Patterns • For components only: • basic patterns. • used by more complex patterns. • Explaining existing frameworks: • conceptual view faciliates usage. • Creates a common design language. • Generating new frameworks: • more complex patterns. • Cornerstones of system architectures.

30. Coding Patterns • Applied design patterns: • ”closer to code level”. • only meaningful for a particular language. • include ”programming standards”. • Features: • demonstrate how to combine the language concepts. • give implementations of design patterns for a language.

31. Patterns of Java Swing • JComponent parts: model and UI. • Programmers work with the JComponents: • a glue that holds the MVC together. • JComponent actually extends the (AWT) Components… Model View Controller UI

32. Ex: The JButton Component • JButton = ButtonModel + ButtonUI • Jbutton methods: setModel and setUI. • API ButtonModel: • describes the internal state of the JButton. • query, manipulate, add listeners, fire events… • API ButtonUI: • describes the view and controller of JButton. • paint, geometric info, handle events…

33. Ex (cont): ButtonUI = V+C • V - methods in API: • install, paint, paint pressed, … • C - BasicButtonUIListener: • controller part of the BasicButtonUI • a compound listener for: mouse, mouse motion, and state change.

34. Observer • One-to-many relation between ”subject” and ”observer” objects • When the subject changes state, all observers are notified and updated automatically • Indirect interfacing: the subject does not know what objects are listening • Independence between two aspects: the subject and observer aspects • Ex: java.awt.event.MouseListener is an Observer of the subject class java.awt.Component.

35. Observer: Class Diagram Observers Subject Observer attach(Observer) Detach(Observer) notify() Update() observerState = subject->getState() For all o in observers{ o->Update() } ConcreteObserver ConcreteSubject Update() getState() setState() observerState subjectState

36. Adapter • Convert interface of a class into an interface the clients expect • Cooperation with unforseen classes • You want to use an existing class but the interface is wrong • Ex: java.awt.event.MouseAdapter is an empty implementation of MouseListener

37. Adapter: Class Diagram Adaptee Client Target SpecRequest() Request() Adapter Adaptee -> specRequest() Request()

38. GoF: disassembling MVC • Observer: generalises the pattern of the model-view • Composite: generalises the pattern of composite views • Strategy: generalises the extraction of controller from the view • MVC = observer + composite + strategy

39. Finding appropriate objects. Determining object granularity. Specifying object Interfaces. Specifying object implementations. Putting reuse mechanisms to work. Relating run-time and compile-time structures. Designing for change. How Patterns Solve Problems

40. Habit 1: taking time to reflect. Habit 2: adherence to a structure. Habit 3: being concrete early. Habit 4: keeping Patterns distinct & complementary. Habit 5: presenting Effectively. Habit 6: iterating tirelessly. Habit 7: collecting and incorporating feedback. Reuse Your Design (Vlissedes 1996)

41. A Layered Catalogue (Zimmer) • Basic patterns: • heavily used simple patterns. • basic design rather than patterns. • Generic patterns: • for typical software problems. • Not part of the basic patterns. • Domain specific patterns • e.g. patterns for compiler construction

42. Relations between Patterns[Zimmer PLOP 1]

43. Summing up • Design Patterns for NLP an open field! • Design patterns • are a catalogue of micro-architectures. • can be combined into frameworks. • form a design language for system (macro) architectures. • Gamma is one of the software pioneers: • Dijkstra, Brooks, Hoare,…,and Gamma! • This is important stuff!! 