Introduction and History

Transcription

1 Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek September 15, 2016

2 Content /FHTenL September 15, /28

3 The idea is quite old, although rather young in SE. Keep up a roof. /FHTenL September 15, /28

4 Design Patterns in enigineering The idea of patterns emerged in architecture There is 5000 years of experience in architectural design There is barely 40 years of experience in SE Christopher Alexander A pattern language (1977) The timeless way of building (1979) /FHTenL September 15, /28

5 Definition Alexander s definition Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use the solution a million times over, without ever doing it the same way twice. /FHTenL September 15, /28

6 Examples Street design Problem: slip traffic. Solution: lassoing streets. Problem: kids must be able to learn about their environment to grow up, they must be able to explore safely. Solution: make bicycle paths to enable kids to wander about safely. Building design Problem: a person may get lost between many buildings. Solution: one building should be recognizable as the main building, the starting point. Problem: a person may not know where to go between many buildings. Solution: All entrances should be visible from his viewpoint. /FHTenL September 15, /28

7 Patterns in informatics OOPSLA workshop on patterns (1987) PLoP conference (1994) s book on design patterns (1995) Many books on patterns, based on the GoF patterns, a few which add new patterns. E.g. Buschman et. al. Pattern-Oriented Software Architecture, Fowler with Catalog of Patterns of Enterprise Application Architecture. We will add some patterns that have become influential in Java: pipes and filters, described by Buschmann. Dependency injection, described by Fowler. /FHTenL September 15, /28

8 The Gang The Design Patterns, subtitle Elements of Reusable Object-Oriented Software has been written in 1994 by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch. and published by Addison-Wesley. ISBN /FHTenL September 15, /28

9 Systematic Pattern Catalogue Patterns are placed in three categories Creational patterns: defer object creation to derived classes or to another object Structural patterns: patterns to compose classes or objects Behavioral patterns: derivation and composition to achieve intricate flow of control or task handling Creational Patterns Structural Patterns Behavioral Patterns /FHTenL September 15, /28

10 Patterns are described systematically Name and classification Intent Also known as Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample code Known uses Related patterns Intent Also Known As Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample Code Known Uses Related Patterns /FHTenL September 15, /28

11 GoF Patterns list (23) Creational patterns Builder Factory Method Prototype Singleton Structural patterns Adapter Bridge Decorator Facade Flyweight Proxy Behavioral patterns Chain of Responsibility Command Interpreter Iterator Mediator Memento State Strategy Template Method Visitor /FHTenL September 15, /28

12 Classification: Creational Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Motivation: User-interface toolkit: Clients should be independent of the particular specialization that may be created. Window ScrollBar PMWindow MotifWindow PMScrollBar MotifScrollBar /FHTenL September 15, /28

13 Instance WidgetFactory Client CreateScrollBar() CreateScroBar() CreateWindow() Window MotifWidgetFactory PMWidgetFactory PMWindow MotifWindow CreateScrollBar() CreateWindow() CreateScrollBar() CreateWindow() ScrollBar PMScrollBar MotifScrollBar /FHTenL September 15, /28

14 Structure AbstrFactory AbstractFactory CreateProductA() CreatePuctA() CreateProductB() CreatePctB() AbstractProductA Client ConcreteFactory2 ConcreteFactory1 ProductA1 ProductA2 CreateProductA() CreateProductB() CreateProductA() CreateProductB() AbstractProductB ProductB1 ProductB2 /FHTenL September 15, /28

15 Participants: AbstractFactory: declares an interface for operations that create abstract products. ConcreteFactory: implements the operation to create concrete products. AbstractProduct: declares an interface for a type of product. ConcreteProduct: defines a products to be created by the corresponding concrete factory and implements the product interface. Client: uses only the interfaces of the abstract factory and a abstract products. /FHTenL September 15, /28

16 Prevents coupling Concrete product objects are created without referring to their classes directly. No reference to software platform (as in example, Motif, PM). Client is independent of concrete product implementation. Client is only coupled to abstraction of products. /FHTenL September 15, /28

17 Classification: Structural Intent: Compose objects into tree structure to represent part-whole hierarchies. lets clients treat individual objects and compositions of objects uniformly. Motivation: In computer science there are often hierarchical composite structures. Examples: File systems Program texts Windows based user interfaces... apicture apicture aline arectangle Take a graphics object: atext aline arectangle /FHTenL September 15, /28

18 Pattern Instance Graphic graphics Draw() Add(Graphic) * Remove(Graphic) GetChild(int) Line Rectangle Text Picture Draw() Draw() Draw() Draw() Add(Graphic) Remove(Graphic) GetChild(int) forall g in in graphics g.draw() add g to to list of of graphics /FHTenL September 15, /28

19 Pattern Structure Component Client Operation() AddComponent() RemoveComponent() GetChildren() children * Leaf Operation() Operation() AddComponent() RemoveComponent() GetChildren() forall g in children g.operation(); /FHTenL September 15, /28

20 Participants: Component declares interfaces for objects in the composition implements common behavior for the interfaces declares an interface for accessing children if desired declares interface for accessing parents Leaf a leaf has no children recursive operation propagation ends here implements abstract operations defines behavior for components with children keeps record of children propagates invocations to children Client accesses the structure as single component /FHTenL September 15, /28

21 Applicability: You want to represent part-whole hierarchies of objects You want to be able to ignore differences between compositions of objects and individual ones. Prevents coupling: Couples a client only to the top of a hierarchy New components (Leafs and s) can be added conveniently. /FHTenL September 15, /28

22 Classification: Behavioral Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Motivation: Maintain consistency among objects that realise collective or distributed behavior without introducing strong coupling. /FHTenL September 15, /28

23 Pattern Structure Subject Attach() Detach(Obsever) Notify() for all o in observers { o.update() } observers * Update() ConcreteSubject subjectstate GetState() SetState() subject Concrete observerstate Update() observerstate= subject.getstate() return subjectstate /FHTenL September 15, /28

24 Participants: Subject: knows its observers. Any number of observers may observe a subject. provides an interface for dynamically adding/removing observers. : defines an interface for being notified. ConcreteSubject: stores and supplies state of interest for observers. notifies observers about state change. Concrete: maintains reference to concrete subject. stores state that has to be kept consistent with subject. implements update procedure. /FHTenL September 15, /28

25 Applicability: If a small selection of many objects depend on the state of a subject and you want an efficient update mechanism. /FHTenL September 15, /28

26 Modifying Dependencies ConcreteSubject subjectstate GetState() SetState() subject observers Concrete observerstate Update() * Subject Attach() Detach(Obsever) Notify() observers * Update() ConcreteSubject subjectstate GetState() SetState() subject Concrete observerstate Update() /FHTenL September 15, /28

27 Traditional Trick Problem: Example: Solution: A component must call a function of another component We don t want a dependency though (coupling) OS must call (inform) an application OS should not depend on the application (coupling) The OS prescribes the call syntax (and possibly semantics) This is called a call back 1 The OS declares function pointers with certain function signature 2 The Appl submits pointers to function implementation 3 The OS uses the pointer to call back the application /FHTenL September 15, /28

28 Call back in C The OS declares function pointers with certain function signature void (* cb) ( argt ); The Appl submits pointers to function implementation void f( argt fa) { /*... */ }; The OS uses the pointer to call back the application cb =&f; cb(aa ); /FHTenL September 15, /28