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

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”

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

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)

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

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

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 routines Idea 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

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

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

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

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

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

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

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

Adapter Pattern

Adapter pattern enabled me to continue to use polymorphism with Shape

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

Comparing Adapter with Façade Both Adapter and Façade are “object wrappers” – wrapping an existing interface with a new interface FaçadeAdapter Are there pre-existing classes?Yes Is there an interface we must design to? NoYes Does an object need to behave polymorphically? NoProbably Is a simpler interface needed?YesNo

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).

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

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

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

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

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

Object-Oriented Design: A New Perspective