PA103 - Object-oriented Methods for Design of Information Systems Design Patterns (cont.) © Radek Ošlejšek Fakulta informatiky MU oslejsek@fi.muni.cz PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 2Spring 2016 State – Motivation Visually similar to Strategy and also with similar purpose. Allow an object to alter its behavior when its internal state changes. +handle(Document) <> PrinterState +handle(Document) Ready +handle(Document) Printing +handle(Document) OutOfToner +print(Document) Printer state PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 3Spring 2016 State Pattern +handle() <> State +handle() ConcreteStateA +handle() ConcreteStateB +request() Context state Context delegates state-specific requests to the current ConcreteState object. A context may pass itself as an argument to the State object handling the request. This lets the State object access the context if necessary. Context is the primary interface for clients. Clients can configure a context with State objects. Once a context is configured, its clients don't have to deal with the State objects directly. Either Context or the ConcreteState subclasses can decide which state succeeds another and under what circumstances. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 4Spring 2016 State Properties  Applicability: Use State when  an object's behavior depends on its state, and it must change its behavior at run-time depending on that state.  operations have large, multipart conditional statements that depend on the object's state.  Consequences:  It localizes state-specific behavior and partitions behavior for different states.  It makes state transitions explicit.  State objects can be shared (see Flyweight pattern later). PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 5Spring 2016 Adapter – Motivation Also known as wrapper. Converts interface to compatible form. Similar principle to spanner bit sockets or power plug adapters. See e.g. java.owt.WindowsAdapter Client +display(x, y, w, h) <> Shape +display(x, y, w, h) Rectangle +show(x1, y1, x2, y2) LegacyRectangle PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 6Spring 2016 Class Adapter request() methods adapted by multiple inheritance. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 7Spring 2016 Object Adapter Request() methods adapted by re-sending to associated adaptee. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 8Spring 2016 Adapter Properties  Applicability: Use the Adapter pattern when  you want to use an existing class, and its interface does not match the one you need.  you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.  (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 9Spring 2016  Consequences (class adapter):  adapts Adaptee to Target by committing to a concrete Adapter class. As a consequence, a class adapter won't work when we want to adapt a class and all its subclasses.  lets Adapter override some of Adaptee's behavior, since Adapter is a subclass of Adaptee.  introduces only one object, and no additional pointer indirection is needed to get to the adaptee.  Consequences (object adapter):  lets a single Adapter work with many Adaptees – that is, the Adaptee itself and all of its subclasses (if any).  makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making Adapter refer to the subclass rather than the Adaptee itself. Adapter Properties (cont.) PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 11Spring 2016 Decorator Pattern – Another Example +getLabel() +getPrice() Pizza PizzaWithSuasage PizzaWithCheese PizzaWithSpinach PizzaWithSausageAndCheese PizzaWithSuasageAndCheeseAndSpinach PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 12Spring 2016 Decorator Pattern – Another Example Sometimes we want to add responsibilities to individual objects, not to an entire class. Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. aPizza getLabel getPrice getLabel getPrice aPizza aCheese aSausage getLabel getPrice getLabel getPrice getLabel getPrice aCheese PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 13Spring 2016 Decorator Pattern Decorator subclasses are free to add operations for specific functionality. The important aspect of this pattern is that it lets decorators appear anywhere a Component can. Important difference from Composite Important difference from Composite PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 14Spring 2016 Decorator Properties  Applicability: Use Decorator  to add responsibilities to individual objects dynamically and transparently, that is without affecting other objects.  for responsibilities that can be withdrawn.  when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination.  Consequences:  More flexibility than static inheritance.  Avoids feature-laden classes high up in the hierarchy. Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects.  Liability: A decorator and its component aren't identical.  Liability: Lots of little objects. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 15Spring 2016 Decorator – Related Patterns and Applications  Adapter: A decorator is different from an adapter in that a decorator only changes an object's responsibilities, not its interface; an adapter will give an object a completely new interface.  Composite: A decorator can be viewed as a degenerate composite with only one component. However, a decorator adds additional responsibilities—it isn't intended for object aggregation.  Strategy: A decorator lets you change the skin of an object; a strategy lets you change the guts. These are two alternative ways of changing an object.  Question: Which standard well-known part of Java API is designed as Decorator? java.io.BufferedReader, ... PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 16Spring 2016 Decorator – Case Study This is our previous model of “shaking” atoms decomposed by Strategy pattern. How it could come off when we apply Decorator pattern instead? -positions : Vector3[] +getPosition(frame : int) : Vector3 <> AllInMemStrategy -posBuffer : Dequeue +getPosition(frame : int) : Vector3 <> BufferedStrategy +getPosition(frame : int) : Vector3 <> AtomPositionStrategy 1 Every atom can have its own strategy +getPosition(frame : int) : Vector3 <> Atom -name : String PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 17Spring 2016 Decorator – Case Study (cont.) +getPosition() : Vector3 <> StaticAtom -posBuffer : Dequeue <> BufferedAtom -position : Vector3[] +goToFrame(frame : int) <> AllInMemAtom +DynamicAtom(component : Atom, src : File) +firstFrame() +nextFrame() +previousFrame() <> DynamicAtom +getPosition() : Vector3 <> Atom 1 componentcomponent 1 +operation() Component +operation() ConcreteComponent +operation() Decorator -addedState +operation() ConcreteDecoratorA +operation() +addedBehaviour() ConcreteDecoratorB 1 component PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 18Spring 2016 Abstract Factory – Motivation +createSctrollBar() +createWindow() <> WidgetFactory +createSctrollBar() +createWindow() AndroidWidgetFactory +createSctrollBar() +createWindow() IOSWidgetFactory <> Window <> ScrollBar AndroidWindowISOWindow AndroidScrollBarIOSScrollBar Client <> <> PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 19Spring 2016 Abstract Factory Pattern +createProductA() +createProductB() <> AbstractFactory +createProductA() +createProductB() ConreteFactory1 +createProductA() +createProductB() ConcreteFactory2 AbstractProductA AbstractProductB ProductA1ProductA2 ProductB1ProductB2 Client <> <> <> PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 20Spring 2016 Abstract Factory Properties  Applicability: Use the Abstract Factory pattern when  A system should be independent of how its products are created, composed, and represented.  A system should be configured with one of multiple families of products.  A family of related product objects is designed to be used together, and you need to enforce this constraint.  You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.  Consequences:  It isolates clients from implementation classes.  It makes exchanging product families easy.  It promotes consistency among products.  Supporting new kinds of products is difficult. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 21Spring 2016 Flyweight Pattern – Motivation + Flexibility at the finest levels, e.g. character set assign to each character. - Even moderate-sized documents may require hundreds of thousands of character objects. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 22Spring 2016 Flyweight Pattern aClient aClient aFlyweightFactory aConcreteFlyweight aConcreteFlyweight A flyweight is a shared object that can be used in multiple contexts simultaneously. Intrinsic state is stored in the flyweight; it consists of information that's independent of the flyweight's context, thereby making it sharable. Extrinsic state depends on and varies with the flyweight's context and therefore can't be shared. Client objects are responsible for passing extrinsic state to the flyweight when it needs it. +getFlyweight(key) FlayweightFactory +operation(extrinsicState) Flyweightflyweights * Client -intrinsicState +operation(extrinsicState) ConcreteFlyweight *flyweights -allState +operation(extrinsicState) UnsharedConcreteFlyweight Not all Flyweight subclasses need to be shared, e.g. row/column. The Flyweight interface enables sharing, it doesn't enforce it. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 23Spring 2016 Flyweight Properties  Applicability: Apply the Flyweight pattern when all of the following are true:  An application uses a large number of objects.  Storage costs are high because of the sheer quantity of objects.  Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed.  The application doesn't depend on object identity. Since flyweight objects may be shared, identity tests will return true for conceptually distinct objects.  Consequences:  Flyweights may introduce run-time costs associated with transferring, finding, and/or computing extrinsic state, especially if it was formerly stored as intrinsic state. However, such costs are offset by space savings.  Storage savings are a function of several factors:  the reduction in the total number of instances that comes from sharing  the amount of intrinsic state per object  whether extrinsic state is computed or stored.  The more flyweights are shared, the greater the storage savings.  The Flyweight pattern is often combined with the Composite pattern to represent a hierarchical structure as a graph with shared leaf nodes. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 24Spring 2016 Flyweight – Case Study Problem: Typical molecule consist of thousands of atoms of a few types, e.g. Oxygen and Hydrogen. Instantiating individual object for every single atom waste the memory because some pieces of information can be shared, e.g. atom name, charge, temperature factor, etc. On the other hand, some data are specific for each atom, e.g. the 3D position (calculated by means of the position strategy). -positions : Vector3[] +getPosition(frame : int) : Vector3 <> AllInMemStrategy -posBuffer : Dequeue +getPosition(frame : int) : Vector3 <> BufferedStrategy +getPosition(frame : int) : Vector3 <> AtomPositionStrategy 1 Every atom can have its own strategy +getPosition(frame : int) : Vector3 <> Atom -name : String PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 25Spring 2016 Flyweight – Case Study +getPosition(atom : Atom, frame : int) : Vector3 <> <> Model ChemStructure Molecule Residue -name : String +setColor() +getPosition(strategy : AtomPositionStrategy) : Vector3 <> <> <> Atom +add(ModelElement) +remove(ModelElement) +get(int) : ModelElement +setColor() <> <> ModelElement +add(ModelElement) +remove(ModelElement) +get(int) : ModelElement +setColor() <> <> GroupElement -periodicTable : Atom[] +getAtom(name) : Atom +getMolecule(name) : Molecule +loadChemStructure(File) : ChemStructure <> <> ChemicalFactory superElement subElements 1..* *periodic table element 1 <> AtomPositionStrategy AtomPositionContext 1 1..* subElements superElement periodic table element * * 1 1 * AllInMemStrategy BufferedStrategy <> PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 26Spring 2016 Memento Pattern capture and externalize an object's internal state so that the object can be restored to this state later PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 27Spring 2016 Memento - cooperation PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 28Spring 2016 Memento - properties  Applicability: Use the Memento pattern when  a snapshot of (some portion of) an object's state must be saved so that it can be restored to that state later, and  a direct interface to obtaining the state would expose implementation details and break the object's encapsulation.  Consequences:  Preserving encapsulation boundaries.  It simplifies Originator. In other encapsulation-preserving designs, Originator keeps the versions of internal state that clients have requested. That puts all the storage management burden on Originator.  Using mementos might be expensive. Mementos might incur considerable overhead if Originator must copy large amounts of information to store in the memento or if clients create and return mementos to the originator often enough.  Defining narrow and wide interfaces. It may be difficult in some languages to ensure that only the originator can access the memento's state.  Hidden costs in caring for mementos. A caretaker is responsible for deleting the mementos it cares for. However, the caretaker has no idea how much state is in the memento. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 29Spring 2016 Observer – Motivation PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 30Spring 2016 Observer Pattern PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 31Spring 2016 Observer – Collaborations PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 32Spring 2016 Observer Properties  Applicability: Use the Observer pattern in any of the following situations:  When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.  When a change to one object requires changing others, and you don't know how many objects need to be changed.  When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled.  Consequences:  Abstract coupling between Subject and Observer. All a subject knows is that it has a list of observers, each conforming to the simple interface of the abstract Observer class.  Support for broadcast communication.  Unexpected updates. Because observers have no knowledge of each other's presence, they can be blind to the ultimate cost of changing the subject. A seemingly innocuous operation on the subject may cause a cascade of updates to observers and their dependent objects. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 33Spring 2016 Proxy Pattern Example: mobile applications Client +request() Subject +request() RealSubject +request() ProxyrealSubj 1 : Client : Proxy : RealSubject PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 34Spring 2016 Proxy Properties  Applicability: Proxy is applicable whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer. Here are several common situations in which the Proxy pattern is applicable:  A remote proxy provides a local representative for an object in a different address space.  A virtual proxy creates expensive objects on demand.  A protection proxy controls access to the original object.  A smart reference is a replacement for a bare pointer that performs additional actions when an object is accessed.  Consequences: The Proxy pattern introduces a level of indirection when accessing an object. The additional indirection has many uses, depending on the kind of proxy:  A remote proxy can hide the fact that an object resides in a different address space.  A virtual proxy can perform optimizations such as creating an object on demand.  Both protection proxies and smart references allow additional housekeeping tasks when an object is accessed. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 35Spring 2016 Bridge – Motivation PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 36Spring 2016 Bridge Pattern PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 37Spring 2016 Bridge Properties  Applicability: Use the Bridge pattern when:  you want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time.  both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently.  changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled.  you have a proliferation of classes. Such a class hierarchy indicates the need for splitting an object into two parts.  Consequences:  Decoupling interface and implementation.  Improved extensibility.  Hiding implementation details from clients.  Question: Which part of java.io is designed as Bridge? PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 38Spring 2016 Facade – Motivation PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 39Spring 2016 Facade – Motivation (cont.) PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 40Spring 2016 Facade Pattern PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 41Spring 2016 Facade Properties  Applicability: Use the Facade pattern when:  you want to provide a simple interface to a complex subsystem.  there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.  you want to layer your subsystems. Use a facade to define an entry point to each subsystem level.  Consequences:  It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use.  It promotes weak coupling between the subsystem and its clients.  It doesn't prevent applications from using subsystem classes if they need to. Thus you can choose between ease of use and generality. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 42Spring 2016 Builder -- Motivation PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 43Spring 2016 Builder Pattern PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 44Spring 2016 Builder – Collaborations PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 45Spring 2016 Builder Properties  Applicability: Use the Builder pattern when  the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled.  the construction process must allow different representations for the object that's constructed.  Consequences:  It lets you vary a product's internal representation.  It isolates code for construction and representation.  Each ConcreteBuilder contains all the code to create and assemble a particular kind of product. The code is written once; then different Directors can reuse it to build Product variants from the same set of parts. In the earlier RTF example, we could define a reader for a format other than RTF, say, an SGMLReader, and use the same TextConverters to generate ASCIIText, TeXText, and TextWidget renditions of SGML documents.  It gives you finer control over the construction process. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 46Spring 2016 Visitor – Motivation PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 47Spring 2016 Visitor Pattern PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 48Spring 2016 Visitor - Collaboration PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 49Spring 2016 Visitor Properties  Applicability: Use the Visitor pattern when  an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes.  many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations.  the classes defining the object structure rarely change, but you often want to define new operations over the structure.  Consequences:  Visitor makes adding new operations easy.  A visitor gathers related operations and separates unrelated ones.  Adding new ConcreteElement classes is hard.  Visiting across class hierarchies. Visitor can visit objects that don't have a common parent class. You can add any type of object to a Visitor interface.  Accumulating state.  Breaking encapsulation. PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 50Spring 2016 Questions?