More Design Patterns

1. More Design Patterns From: Shalloway & Trott, Design Patterns Explained, 2nd ed.

2. Design Patterns Why study design patterns? • Reuse solutions – can learn from the experts • Establish common terminology – design patterns provide a common point of reference during analysis and design Patterns provide a higher-level perspective on the problem and on design See Parnas quote, Brooks p. 221 See also Brooks pp. 224, 225 on “Learning Large Vocabularies”

3. Design Patterns Big picture strategies for creating good object-oriented designs (Gang of Four) • Design to interfaces • Favor aggregation (composition) over inheritance (generalization) • Find what varies and encapsulate it

4. Façade Pattern Intent: “To provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.” (Gang of Four, p. 185)

6. Façade Pattern Idea: Enables one to use a complex system more easily, either • To use just a subset of the system, or • To use the system in a particular way

7. Façade Pattern Example: Suppose I have a Client object that must open a Database to get a Model, then query the Model to get an Element, and finally ask Element for information It is much easier to create a DatabaseFacade that can be queried by the Client

10. Façade Pattern Variation on Façade: • In addition to using functions in the system one could add new functionality, e.g. log all calls to specific routinesIdea of Façade pattern with expanded functionality Façade pattern – I am creating a new interface for the client to use instead of the existing system’s interface

11. Façade Pattern Façade can also be used to hide, or encapsulate, the system=> the Façade object could contain the system as private members Benefits of encapsulating system: • Track system usage • Swap out systems – only have to change code in one place – the Façade

12. Adapter Pattern Intent: “Convert the interface of a class into another interface that the clients expect. Adapter lets classes work together that could not otherwise because of incompatible interfaces.” (Gang of Four, p. 139) Idea: Need to create a new interface for an object that does the right thing but has the wrong interface

13. Adapter Pattern Example: • Suppose I create classes for points, lines, square that have the behavior “display” • Client should not have to know whether they actually have a point, a line, a square. They just want to know that they have one of these shapes

14. Adapter Pattern Example (cont): • Using polymorphism there will be different types of objects but the clients interact with them in a common way • Define an interface (in this case the abstract class Shape) from which the other classes are derived

15. Adapter Pattern

16. Adapter Pattern • Now suppose I need to implement a circle – a new kind of Shape • So I create a new class Circle that extends Shape and I need to code display, fill, undisplay • However, I find that another programmer has already written a class XXCircle that does what I want except the names of the methods aren’t what I require

17. Adapter Pattern • XXCircle has methods: displayIt, fillIt, undisplayIt • Two reasons I cannot directly use XXCircle: • I have different names and parameter lists • It does not extend Shape

18. Adapter Pattern • Rather than change XXCircle I adapt it • I make a new class Circle: • Circle extends Shape • Circle contains XXCircle • Circle passes messages through (“delegates”) to the XXCircle object

19. Adapter Pattern

20. Adapter Pattern

21. Adapter Pattern Adapter pattern enabled me to continue to use polymorphism with Shape

22. Adapter Pattern

23. Adapter Pattern Variations – there are two types of Adapter patterns: • Object Adapter pattern – one object (adapting object) contains another object (adapted object) • Class Adapter pattern – using multiple inheritance the adapter class • Derives publicly from the abstract class to define its interface • Derives privately from existing class to access its implementation

24. Comparing Adapter with Façade Both Adapter and Façade are “object wrappers” – wrapping an existing interface with a new interface

25. Comparing Adapter with Façade Bottom line: A Façade simplifies an interface while an Adapter converts a pre-existing interface into another interface (usually in the context of polymorphism).

26. Object-Oriented Design:A New Perspective Object Traditional view: object = data with methods New view: object = entity that has responsibilities Responsibilities define the behavior of the object

27. Object-Oriented Design:A New Perspective Better definition since focus is on what objects are supposed to do not on how they are implemented Recurring theme of design patterns: Focus on motivation rather than on implementation

28. Object-Oriented Design:A New Perspective Encapsulation Traditional view: Encapsulation = data hiding New view: Encapsulation = any kind of hiding

29. Object-Oriented Design:A New Perspective Encapsulation – can hide • Implementations • Derived classes • Design details • Instantiation rules

30. Object-Oriented Design:A New Perspective Examples of encapsulation: • Encapsulation of data – the data in Point, Line, Square, Circle are hidden from everything else • Encapsulation of methods – e.g. Circle’s setLocation • Encapsulation of other objects – Nothing but Circle is aware of XXCircle • Encapsulation of type – Clients of Shape know nothing of Point, Line, Square, Circle

31. Object-Oriented Design:A New Perspective