Design Patterns Introduction Patterns are discovered not invented

Design Patterns Introduction “Patterns are discovered, not invented” Richard Helm

What’s a pattern? o A pattern is a named abstraction from a concrete form that represents a recurring solution to a particular problem.

Categories of Patterns o Design patterns vary in granularity and level of abstraction. o By categorizing patterns, it becomes easier to recognize and learn them o patterns can be categorized by purpose or scope o purpose reflects what the pattern does o scope specifies if the pattern applies to classes or objects

purpose o reflects what the pattern does o Creational -- facilitate object creation o Structural -- deal with the composition of classes or objects o Behavioral -- deal with the way objects interact and distribute responsibility

scope o whether the pattern applies to classes or objects o class patterns: n deal with relationships between classes or subclasses established through inheritance n these relationships are fixed at compile time o objects patterns: deal with object relationships that can be changed at runtime

other ways to organize patterns o some patterns are frequently used with other patterns, for example composite is often used with visitor and/or iterator o some patterns are alternatives: Prototype is usually an alternative for Abstract Factory o Some patterns are very similar in structure, such as Composite and Decorator

How do Design Patterns Solve Design Problems? o The meaning of OO is well-known o The hard part is decomposing the system into objects to exploit: n n n encapsulation flexibility, extensibility ease of modification performance evolution reusability

Finding objects o Many objects in the design come from the analysis model o But OO designs often end up with classes that have no counterpart in the real world o Design Patterns help the modeler to identify less obvious abstractions and the objects that can capture them.

Inheritance o Inheritance is a mechanism for reuse o you can define a new kind of object in terms of the old one o you get new implementations almost for free, inheriting most of what you need from an existing class o This is only half the story!

Program to an interface, not an implementation o Inheritance permits defining a family of objects with identical interfaces o polymorphism depends on this! o all derived classes share the base class interface o Subclasses add or override 0 perations, rather than hiding operations o All subclasses then respond to requests in the interface of the abstract class

Inheritance properly used o clients are unaware of types of objects: heuristic 5. 12 - “explicit case analysis on the type of an object is usually an error. The designer should use polymorphism”. Riel o clients only know about the abstract classes defining the interface. heuristic 5. 7: “All base classes should be abstract”. Riel o This reduces implementation dependencies o program to an interface, not an implementation o creational patterns help ensure this rule!

Two techniques for reuse o inheritance: white box o object composition: black box

advantage of inheritance for reuse o defined statically o supported directly by the language: straightforward to use o easier to modify implementation being reused

disadvantage of inheritance o can’t change inherited implementation at runtime o parent classes often define part of their subclass’s physical representation o because inheritance exposes the parent implementation it’s said to “break encapsulation” (GOF p. 19, Sny 86) o change in parent => change in subclass o What if inherited attribute is inappropriate?

object composition: black box reuse o objects are accessed solely through their interfaces: no break of encapsulation o any object can be replaced by another at runtime: as long as they are the same type o favor object composition over class inheritance. GOF p. 20 o but inheritance & composition work together!

Delegation o “a way of making composition as powerful for reuse as inheritance”: n GOF, p. 20 n [JZ 91] Ralph Johnson and Jonathan Zweig, Delegation in C++, JOOP, f(11): 22 -35, Nov. 91 n [Lie 86] Henry Lieberman. Using prototypical objects to implement shared behavior in OO systems. OOPSLA, pp 214223, Nov. ‘ 86

delegation: reuse o In delegation, 2 objects handle a request o analogous to subclass deferring request to parent o in delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver!

delegating area() to rectangle Rectangle Window area() return rectangle->area() Has-a area() width height return width*height

advantages of delegation o can change behaviors at run-time o window can become square at runtime by replacing Rectangle with Square, (assuming Rectangle & Square same type!) o There are run-time costs. o delegation in patterns: State, Strategy, Visitor, Mediator, Bridge

delegating area() to square Square Window area() return square->area() Has-a area() side return side*side

Patterns make design resistant to re-design Robustness to Change o Algorithmic dependencies: Template Method, Visitor, Iterator, Builder, Strategy. o Creating an object by specifying a class explicitly: Abstract Factory, Factory Method, Prototype o Dependence on specific operations: Command, Chain of Responsibility o Dependence on object representation or implementation: Abstract Factory, Bridge, Proxy o Tight coupling: Abstract Factory, Command, Facade, Mediator, Observer, Bridge

Patterns make design resistant to redesign o Extending functionality by subclassing: Command, Bridge, Composite, Decorator, Observer, Strategy o Inability to alter classes conveniently: Visitor, Adapter, Decorator

Design Confidence o Design Inexperience: “Is my design ok? ” o Patterns engender confidence n used twice & blame the GOF n still room for creativity

Design Coverage o Large portion of design can be covered by patterns o Seductively simple to implement n most explained in a few pages n add no “extra-value” to end-user o You still have to write functionality: patterns don’t solve the problem

Design Understanding o Most people know the patterns If you’re looking at someone’s design & you identify a pattern, you immediately understand much of the design o Common design vocabulary n “Let’s use a Builder here” o Design language beyond language syntax n Problem-oriented language n program in rather than into the language

Common Problems o Getting the “right” pattern o Taming over-enthusiasm n you “win” if you use the most patterns n everything solved by the last pattern you learned

How to select a pattern o o know a basic catalog scan intent section study patterns of like purpose consider a cause of redesign