UNITIII Structural Design Patterns Objectives S No Topic
UNIT-III Structural Design Patterns
Objectives S. No Topic PPT Slides To introduce structural design patterns 1. Decorator L 1 3 – 20 2. Façade L 2 21 – 27 3. Proxy L 3 28 – 40 4. Flyweight L 4 41 – 47 5. Repeated key points for Structural Patterns L 5 48 – 52 6. (Intent, Motivation, Also Known As ……………) L 6 53 – 57 7. Review Unit-V L 7 58 – 58
L 1 Decorator Design Pattern • Design Purpose • Add responsibilities to an object at runtime. • Design Pattern Summary – Provide for a linked list of objects, each encapsulating responsibility.
L 1 Decorator: Class Model Decorator creates an aggregated linked list of Decoration objects ending with the basic Substance object.
L 1 Pattern: Decorator objects that wrap around other objects to add useful features
Decorator pattern L 1 • decorator: an object that modifies behavior of, or adds features to, another object – decorator must maintain the common interface of the object it wraps up • used so that we can add features to an existing simple object without needing to disrupt the interface that client code expects when using the simple object • examples in Java: – multilayered input streams adding useful I/O methods – adding designs, scroll bars and borders to GUI controls
Decorator example: I/O L 1 • normal Input. Stream class has only public int read() method to read one letter at a time • decorators such as Buffered. Reader or Scanner additional functionality to read the stream more easily // Input. Stream. Reader/Buffered. Reader decorate Input. Stream in = new File. Input. Stream("hardcode. txt"); Input. Stream. Reader isr = new Input. Stream. Reader(in); Buffered. Reader br = new Buffered. Reader(isr); // because of decorator streams, I can read an // entire line from the file in one call // (Input. Stream only provides public int read() ) String whole. Line = br. read. Line();
Decorator example: GUI L 1 • normal GUI components don't have scroll bars • JScroll. Pane is a container with scroll bars to which you can add any component to make it scrollable // JScroll. Pane decorates GUI components JText. Area area = new JText. Area(20, 30); JScroll. Pane scroll. Pane = new JScroll. Pane(area); content. Pane. add(scroll. Pane);
An example: Decorator Intent: Allow to attach responsibilities to objects, extend their functionality, dynamically Motivation: Consider a WYSIWYG editor The basic text. Window needs various decorations: borders, tool bars, scroll bars, … L 1
L 1 An “obvious” solution: sub-classing • A sub-class for every option Disadvantages: • Sub-classing is static – compile-time • # of sub-classes = # of combinations – exponential
L 1 The preferred solution: Use decorator objects • Each decorator adds one decoration – property, behavior Linear • Can add more than one, to obtain combinations of properties • And, do it dynamically
L 1 Structure, participants, collaborations: • Component – an interface, describes the operations of a (GUI) component • Concrete. Component (extends Component) class of objects to which decorations can be added (e. g. the original Text. Window) • Decorator (extends Component)– a class of decorator objects (there are several such classes)
L 1 Implementation: • Each decorator has a (private) reference to a Component object (CC or D) • For each operation, the decorator performs its decoration job, & delegates Component operations to the Component object it contains • Decorator extends Component (can accept Component requests)
L 1 Decorators can perform all the operations of Component, often more Decorators can be combined : D 3 D 2 D 1 CC (but some combinations may hide some functionalities)
L 1 The decorator pattern <<Interface>> Component Decorator Various decorators Concrete. Component
L 1 Consequences : • Decoration can be done dynamically, at run -time • When it makes sense, a decoration can be added several times • The # of decorators is smaller than the # of sub-classes in original solution; avoids lots of feature-heavy classes in the inheritance hierarchy
L 1 Issues to remember : • A decorator and the Component object it contains are not identical • Many small objects; one has to learn their roles, the legal connections, etc. (but, still much better than sub-classing)
L 1 Decorators in a java library: Stream decorators A byte stream – r or w bytes Decorators add: • Buffering (does not add services) • r or w primitive types, objects, … (adds services)
Lessons from Decorator More dynamic, flexible, less expensive Composition is (often) superior to sub-classing Program to interfaces, not to concrete classes L 1
L 1 Facade Design Pattern • Design Purpose • Provide an interface to a package of classes. • Design Pattern Summary – Define a singleton which is the sole means for obtaining functionality from the package.
L 2 Façade (2) • Example: graph interface to a simulation engine Schematic. Editor Graph 2 Relation Port 0. . * Director Entity Buffered. Relation Atomic. Entity Token Actor Composite. Entity
Facade: Encapsulating Subsystems Name: Facade design pattern Problem description: Reduce coupling between a set of related classes and the rest of the system. Solution: A single Facade class implements a high-level interface for a subsystem by invoking the methods of the lower-level classes. Example. A Compiler is composed of several classes: Lexical. Analyzer, Parser, Code. Generator, etc. A caller, invokes only the Compiler (Facade) class, which invokes the contained classes. L 2
Facade: Class Diagram Facade L 2 Facade service() Class 1 Class 2 Class 3 service 1() service 2() service 3()
Facade: Consequences: Shields a client from the low-level classes of a subsystem. Simplifies the use of a subsystem by providing higher-level methods. Enables lower-level classes to be restructured without changes to clients. Note. The repeated use of Facade patterns yields a layered system. L 2
L 2 Facade: Motivation • Clients communicate with the package (subsystem ) by sending requests to Facade, which forwards them to the appropriate package object(s).
L 2 Facade: Applicability • To provide simple interface to a complex package, which is useful for most clients. • To reduce the dependencies between the client and the package, or dependencies between various packages.
L 2 Facade: Consequences • It shields clients from package components, thereby reducing the number of objects that clients deal with and making the package easier to use. • It promotes weak coupling between the package and its clients and other packages, thereby promoting package independence and portability.
L 3 Proxy • You want to – delay expensive computations, – use memory only when needed, or – check access before loading an object into memory • Proxy – has same interface as Real object – stores subset of attributes – does lazy evaluation
Proxy Design Pattern • Design Purpose • Avoid the unnecessary execution of expensive functionality in a manner transparent to clients. • Design Pattern Summary – Interpose a substitute class which accesses the expensive functionality only when required. L 3
L 3 Proxy: Class Model
L 3 Proxy: Class Model
L 3 Telephone Record Example
Telephone Record Example (Cont’d) L 3
Proxy: Consequences L 3 • Proxy promotes: – Efficiency: avoids time-consuming operations when necessary. – Correctness: separates design and code that are independent of retrieval/efficiency from parts concerned with this issue. – Reusability: design and code that are independent of retrieval efficiency are most likely to be reusable. – Flexibility: we can replace one module concerned with retrieval with another. – Robustness: isolates parts that check for the validity of retrieved data.
Proxy: Encapsulating Expensive Objects Name: Proxy design pattern Problem description: Improve performance or security of a system by delaying expensive computations, using memory only when needed, or checking access before loading an object into memory. Solution: The Proxy. Object class acts on behalf of a Real. Object class. Both implement the same interface. Proxy. Object stores a subset of the attributes of Real. Object. Proxy. Object handles certain requests, whereas others are delegated to Real. Object. After delegation, the Real. Object is created and loaded into memory. L 3
Proxy: Class Diagram Client Object filename op 1() op 2() Proxy. Object filename op 1() op 2() 1 0. . 1 Real. Object data: byte[] op 1() op 2() L 3
L 3 Proxy: Consequences: Adds a level of indirection between Client and Real. Object. The Client is shielded from any optimization for creating Real. Objects.
L 3 Pattern Hatching Proxy Pattern Subject request() … Real. Subject request() … real. Subject->request(); Proxy request() …
L 3 Pattern Hatching 4 Proxy Pattern 8 We need to find a common structure for the proxy pattern with our composite pattern 8 As we recognize, our common interface that we still want to use for the file-system is Node 8 And because the Composite structure uses a common interface already, we can combine the Proxy “Subject” Interface into our Node Interface
L 3 Pattern Hatching Node get. Name() stream. In(istream) stream. Out(ostream) get. Child(int) adopt(Node) orphan(Node) Composite Pattern children subject Proxy Pattern Link File Directory stream. In(istream) stream. Out(ostream) get. Subject() stream. In(istream) stream. Out(ostream) get. Child(int) adopt(Node) orphan(Node)
L 4 Flyweight Design Pattern • Design Purpose • Manage a large number of objects without constructing them all. • Design Pattern Summary – Share representatives for the objects; use context to obtain the effect of multiple instances.
L 4 Flyweight: Class Model
L 4 Flyweight: Sequence Diagram
L 4 Text Magnifier Example
L 4 Text Magnifier Example (Cont’d)
L 4 Text Magnifier Example (Cont’d)
L 4 Flyweight: Consequences • Space savings increase as more flyweights are shared.
L 5 An example: Decorator Intent: Allow to attach responsibilities to objects, extend their functionality, dynamically Motivation: Consider a WYSIWYG editor The basic text. Window needs various decorations: borders, tool bars, scroll bars, … UNIT-V 48
L 5 An “obvious” solution: sub-classing • A sub-class for every option Disadvantages: • Sub-classing is static – compile-time • # of sub-classes = # of combinations – exponential UNIT-V 49
L 5 The preferred solution: Use decorator objects • Each decorator adds one decoration – property, behavior Linear • Can add more than one, to obtain combinations of properties • And, do it dynamically UNIT-V 50
L 5 Structure, participants, collaborations: • Component – an interface, describes the operations of a (GUI) component • Concrete. Component (extends Component) class of objects to which decorations can be added (e. g. the original Text. Window) • Decorator (extends Component)– a class of decorator objects (there are several such classes) UNIT-V 51
L 5 Implementation: • Each decorator has a (private) reference to a Component object (CC or D) • For each operation, the decorator performs its decoration job, & delegates Component operations to the Component object it contains • Decorator extends Component (can accept Component requests) UNIT-V 52
L 6 Facade Design Pattern • Design Purpose • Provide an interface to a package of classes. • Design Pattern Summary – Define a singleton which is the sole means for obtaining functionality from the package. UNIT-V 53
L 6 Façade (2) • Example: graph interface to a simulation engine Schematic. Editor Graph 2 Relation Port 0. . * Director Entity Buffered. Relation Atomic. Entity Token Actor UNIT-V Composite. Entity 54
Facade: Encapsulating Subsystems Name: Facade design pattern Problem description: Reduce coupling between a set of related classes and the rest of the system. Solution: A single Facade class implements a high-level interface for a subsystem by invoking the methods of the lower-level classes. Example. A Compiler is composed of several classes: Lexical. Analyzer, Parser, Code. Generator, etc. A caller, invokes only the Compiler (Facade) class, which invokes the contained classes. UNIT-V 55 L 6
Facade: Class Diagram Facade L 6 Facade service() Class 1 Class 2 Class 3 service 1() service 2() service 3() UNIT-V 56
Facade: Consequences L 6 Consequences: Shields a client from the low-level classes of a subsystem. Simplifies the use of a subsystem by providing higher-level methods. Enables lower-level classes to be restructured without changes to clients. Note. The repeated use of Facade patterns yields a layered system. UNIT-V 57
Summary of Structural Design Patterns • Structural Design Patterns relate objects (as trees, lists etc. ) – – – Facade provides an interface to collections of objects Decorator adds to objects at runtime Composite represents trees of objects Adapter simplifies the use of external functionality Flyweight gains the advantages of using multiple instances while minimizing space penalties – Proxy avoids calling expensive operations unnecessarily L 7
- Slides: 58
