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

Post on 18-Jan-2016

217 views 0 download

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

More Design Patterns

From:

Shalloway & Trott,

Design Patterns Explained, 2nd 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. 221See 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 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

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

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

Adapter Pattern

Adapter pattern enabled me to continue to use polymorphism with Shape

Adapter Pattern

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çade Adapter

Are there pre-existing classes? Yes Yes

Is there an interface we must design to?

No Yes

Does an object need to behave polymorphically?

No Probably

Is a simpler interface needed? Yes No

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