Trott - 2017 - roz Innovation-Management-and-New-Product ...
More Design Patterns From: Shalloway & Trott, Design Patterns Explained, 2 nd ed.
-
Upload
vernon-burns -
Category
Documents
-
view
217 -
download
0
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