Four Design Patterns Composite Observer Adapter Bridge Pattern

Four Design Patterns Composite Observer Adapter Bridge

Pattern Taxonomy Pattern Creational Pattern Structural Pattern Behavioral Pattern Command Adapter Bridge Observer Composite Strategy Proxy Abstract Factory Singleton

Taxonomy cont. Structural Patterns Focus: How objects are composed to form larger structures Problems solved: Realize new functionality from old functionality, Provide flexibility and extensibility Behavioral Patterns Focus: Algorithms and the assignment of responsibilities to objects Problem solved: To tie object coupling to a particular algorithm Creational Patterns Focus: Creation of complex objects Problems solved: Hide how complex objects are created and put together

Observer Design Pattern Intent: Define a one-to-many dependency between objects so that when one subject changes state, all its dependents are notified & updated automatically Motivation: Need to maintain consistency between related objects Applicability: When a change to one object requires changing others. Don’t know how many objects need to be changed When one object should be able to notify other objects without making assumption who they are

Observer-- Structure Subject Observer * Attach(Observer) Detach(Observer) Notify() Update() Concrete. Subject Concrete. Observer subject. State Get. State() Set. State() observer. State Update()

Observer– Sequence Diagram a. Concrete. Subject: a. Concrete. Observer: another. Concrete. Observer: Concrete. Subject Concrete. Observer Set. State() Notify() Update() Get. State()

Observer-- Example Observer Subject * Update() Attach(Observer) Detach(Observer) Notify() Clock. Timer Digital. Clock. Timer sub; Update() Draw() Analog. Clock. Timer sub; Update() Draw()

Composite Design Pattern Intent: Compose objects into tree structures to represent part-whole hierarchies. Let clients treat individual objects and compositions of objects uniformly Motivation: components can be grouped to form larger components a. Picture a. Text a. Line a. LIne a. Rectangle

Graphic Example * Graphic Draw() Add(Graphic) Remove(Graphic) Get. Child(int) Line Draw() Rectangle Draw() Picture Text Draw() Add(Graphic) Remove(Graphic) Get. Child(int)

Composite Pattern: Structure Component * Operation() Add(Component) Remove(Component) Get. Child(int) Leaf Operation() Composite Operation() Add(Component) Remove(Component) Get. Child(int)

Composite Design Pattern: Collaborations Clients use the Component class interface to interact with objects in the composite structure If recipient is a Leaf, then the request is handled directly If recipient is a Composite, it usually forwards requests to its child components

Composite Design Pattern: Example Equipment Card Cabinet Floppy Disk Chassis * Composite Equipment Bus

Adapter Pattern “Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces Used to provide a new interface to existing legacy components Also known as a wrapper Two adapter patterns: Class adapter: Uses multiple inheritance to adapt one interface to another Object adapter: Uses single inheritance and delegation We will use object adapters and call them simply adapters

Class Adapter Pattern (based on Multiple Inheritance) Client Target Adaptee (Legacy Object) Request() Existing. Request() Adapter Request()

Object Adapter Pattern Client Target Adaptee Request() Existing. Request() Adapter Request() Delegation is used to bind an Adapter and an Adaptee Interface inheritance is use to specify the interface of the Adapter class. Target and Adaptee (usually called legacy system) pre-exist the Adapter. Target may be realized as an interface in Java.

Bridge Decouple an abstraction from its implementation so that the two can vary independently. Applicability Need to avoid a permanent binding between an abstraction (type!) and its implementation Both abstractions and implementation should be extensible through subclassing Need to isolate changes in implementations from clients

Example Suppose you have defined a Window in a GUI package. Now you want to support this package on a Macintosh as well as in a Windows environment Window Mac. Window Window You also want to support different kinds of windows Window (e. g. Icons) Mac. Window Window Icon Mac. Icon Win. Icon

Example Problem: a new class has to be defined for every combination of environment and window type Difficult to extend window types and environments Client code is platform-dependent Hierarchies are used for two purposes: - to extend behavior - to provide multiple implementations of identical behavior The bridge defines a separate hierarchy for each purpose …/. . .

Window Draw. Text() Draw. Rect() imp Example imp. Dev. Draw. Line(); Icon. Window Draw. Border() Draw. Rect(); Draw. Text(); Transient. Window Draw. Close. Box() Window. Imp Dev. Draw. Text() Dev. Draw. Line() Window. Imp Mac. Window. Imp Dev. Draw. Text() Dev. Draw. Line() Draw. Rect(); One hierarchy for Window interfaces (Window, Icon. Window, Transient. Window) One hierarchy for platform-dependent implementations (Window. Imp, Window. Imp, Mac. Window. Imp) The relationship between Window and Window. Imp is a bridge between interface and implementation

When to use a Bridge pattern to avoid a permanent binding between an implementation and an interface (e. g. the implementation is switched or selected at run time) both the abstractions and their implementations should be extensible by subtyping changes in the implementation of an abstraction should not affect a client (i. e. you don’t have to recompile the client) you have a proliferation of classes, indicating the need to split hierarchies into different concerns you want to share an implementation among multiple object types, and you want to hide this from a client

Client Abstraction Operation() Bridge pattern imp. Operation. Imp(); Implementor Operation. Imp() Refined. Abstraction 1 Refined. Abstraction 2 Concrete. Implementor. A Concrete. Implementor. B Operation. Imp() Refined. Abstraction 3 Abstraction (Window): defines the abstraction’s interface Refined. Abstraction (Icon. Window): extends the interface defined by Abstraction Implementor (Window. Imp): defines the interface for implementation classes. This interface is different from the Abstraction interface and consists of all primitive methods necessary to implement all Abstraction functionality. Concrete. Implementor (Mac. Window. Imp, Window. Imp): implements the Implementor interfaces and defines a concrete implementation

Consequences Bridge decouples interface and implementation: an implementation is no longer bound permanently to a particular interface. The implementation can change at run time. One implementation can serve multiple abstractions. Improves extensibility: new Abstractions and Implementations can be added independently Hides implementation details from Clients: Clients have no knowledge about implementation objects, do not have to instantiate them, do not have to know whether they are shared, etc. . .

Adapter vs Bridge Similarities: Both used to hide the details of the underlying implementation. Difference: The adapter pattern is geared towards making unrelated components work together Applied to systems after they are designed (reengineering, interface engineering). A bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently.