Patterns 1 Patterns in OO - history 77 - Work of the architect Christopher Alexander 80s - Kent Beck playing with Smalltalk 91 - Gamma’s PhD thesis on ET Coad’s patterns paper 92 - Johnson’s OOPSLA paper 93 - OOPSLA workshop Coad & Anderson 93 - Patterns discussion group on WWW 94 - First PLoP conference 95 - Gang of four book (first draft at OOPSLA 93)

Patterns 2 Christopher Alexander Alexander,C., Ishikawa, S. & Silverstein, M., A Pattern Language, Oxford University Press 1977 This text is handbook of patterns to be used in the construction of built environments. “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 this solution a million times over, without ever doing it the same way twice.” Alexander presented 253 patterns in 35 groups at different levels of abstraction or resolution.

Patterns 3 The structure of a pattern Each pattern is presented in the same format for clarity, ease of navigation etc. Name. A Short descriptive phrase. Picture. Followed by an introductory paragraph to outline the context. Problem. An outline of the problem that the pattern aims to solve. Solution. The heart of the pattern, a description of how to solve the problem. Interconnections. The other patterns which are related to this one.

Patterns 4 Some typical examples Intimacy Gradient Common Areas at the Heart Eating Atmosphere Roof Layout Pools of Light

Patterns 5 Peter Coad’s patterns Coad, P., Object-Oriented Patterns, Communications of the ACM Vol 35 No. 9 September 1992 "An object-oriented pattern is an abstraction of a doublet, triplet, or other small grouping of classes that is likely to be helpful again and again in object-oriented development." Coad’s patterns originally had a focus on OOA.

Patterns 6 Patterns and layers Service Layer Item Description Time Association Event Logging Attribute Layer State across a collection Behaviour across a collection Roles Played Broadcast pattern

Patterns 7 Event logging Use whenever an event is detected and you need to log its occurence

Patterns 8 Larman’s GRASP patterns Larman proposes a small set of (what he calls) patterns for assigning responsibilities to classes. General Responsibility Assignment Software Patterns. Expert, Creator, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection and Don’t Talk to Strangers.

Patterns 9 Grasp 1 Expert - assign the responsibility to the class that has the information necessary to fulfill the responsibility. Creator - Assign B the responsibility to create an A if.. B aggregates or contains A objects B records instances of A objects B closely uses A objects B has the initialising data that A needs (expert) Low coupling - Assign a responsibility so that coupling remains low. High cohesion - Assign a responsibility so that cohesion remains high.

Patterns 10 Grasp 2 Polymorphism - When behaviours vary by type, assign responsibilities (using polymorphism) to the type with the variation. Pure Fabrication - Invent a cohesive class which is not in the problem domain to further low coupling. Indirection - Assign the responsibility to an intermediate object to mediate between components so that they are not directly coupled. Don’t talk to strangers - The Law of Demeter

Patterns 11 Gang of Four Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley Work started with Gamma’s doctoral thesis and continued for a couple of years. The final published book shows signs of evolution from the earliest drafts. You should try to read chapter 2. There are 25 patterns arranged under 3 headings

Patterns 12 Gang of four - format Pattern Name and Classification Intent Also known as Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample code Known uses Related Patterns

Patterns 13 Design Pattern Space Factory Method Abstract Factory Builder Prototype Singleton Adapter (class) Adapter (object) Bridge Composite Decorator Facade Flyweight Proxy Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor Creational StructuralBehavioural Purpose Scope Class Object

Patterns 14 Strategy pattern Intent. Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Context Strategy ContextInterface() ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB ConcreteStrategyC AlgorithmInterface() Motivation A text compositor with a number of line breaking algorithms Structure

Patterns 15 Observer pattern outline abc x y z a b c a b c a = 50% b = 30% c = 20% Change notification requests, modifications

Patterns 16 Observer pattern

Patterns 17 Observer details Defines a one to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Used when you need to maintain consistency between objects. Particularly used in GUI development, it is the basis for Smalltalk’s Model-View-Controller. Also known as Dependents or Publish-Subscribe.

Patterns 18 Abstract Factory Used to provide an interface for creating families of related or dependent objects without specifying their concrete classes. Java uses this pattern in its AWT for creating platform specific objects with the correct look and feel. (Peers)

Patterns 19 Abstract factory

Patterns 20 Patterns and design skills If patterns capture design expertise, then learning patterns makes me an expert designer. Teaching patterns to beginners can help them become better designers. How do I know when to apply a pattern, Riel argues that design heuristics may tell me? Are there such things as anti-patterns? Examples of bad practice to be avoided. A. J. Riel Object-Oriented Design Heuristics Addison-Wesley 1996

Patterns 21 Patterns and reuse The focus was never on component reuse but on the reuse of design ideas and insights. Patterns are increasingly becoming specialised to problem domains, apparently losing generality. Might patterns provide accelerated familiarity with domains for designers? Documenting patterns is hard work, are they worth building?

Patterns 22 The scope and granularity of patterns Scope Coad’s analysis patterns versus Gamma’s design patterns Granularity Coplien’s idioms for C++ Gamma’s patterns Frameworks - implemented patterns

Patterns 23 References Lea, D., Christopher Alexander: An Introduction for Object-Oriented Designers SIGSOFT Jan (lots of references) Beck, K., et al Industrial Experience with Design Patterns proceedings of ICSE Larman, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design Prentice Hall