1 / 45

Structural Pattern part-I introduction

Structural Pattern part-I introduction. S. No TOPIC PPT Slides . Adaptor Bridge Composite. 1. L1 3 – 18. 2. L2 19 – 31. 3. L3 32 – 37. 4. L4 38 – 40. Repeated key points for Structural Patterns. 5. (Intent, Motivation, Also Known As…). L5 41 – 42. 6.

pomalley
Télécharger la présentation

Structural Pattern part-I introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Structural Pattern part-I introduction S. No TOPIC PPT Slides Adaptor Bridge Composite 1 L1 3 – 18 2 L2 19 – 31 3 L3 32 – 37 4 L4 38 – 40 Repeated key points for Structural Patterns 5 (Intent, Motivation, Also Known As…) L5 41 – 42 6 Code Examples L6 43 – 44 7 Reference L7 45 – 45 UNIT-III

  2. Agenda • Intent & Motivation • Structure • Applicability • Consequences • Known Uses • Related Patterns • References UNIT-III

  3. L1 What is Adapter? • Intent: • Change the interface of a class into another interface which is expected by the client. • Also Know As: • Wrapper UNIT-III

  4. Motivation 1 1 L1 UNIT-III

  5. L1 Structure (Class) UNIT-III

  6. L1 Structure (Object) UNIT-III

  7. Want to use several existing subclasses, but it is impractical to subclass everyone. (Object Adapter Only) L1 Applicability • Use an existing class whose interface does not match the requirement • Create a reusable class though the interfaces are not necessary compatible with callers UNIT-III

  8. L1 Class Adapter Pattern • Pros • Only 1 new object, no additional indirection • Less code required than the object Adapter • Can override Adaptee's behaviour as required • Cons • Requires sub-classing (tough for single inheritance) • Less flexible than object Adapter UNIT-III

  9. L1 Object Adapter Pattern • Pros • More flexible than class Adapter • Doesn't require sub-classing to work • Adapter works with Adaptee and all of its subclasses • Cons • Harder to override Adaptee behavior • Requires more code to implement properly UNIT-III

  10. L1 Pluggable Adapters • implemented with abstract operations UNIT-III

  11. L1 Pluggable Adapters • implemented with delegate objects UNIT-III

  12. L1 Two-way Adapters class PegAdapter: public SquarePeg, RoundPeg { public: void virtual roundPegOperation() { add some corners; squarePegOperation(); } void virtual squarePegOperation() { add some corners; roundPegOperation(); } } class SquarePeg { public: void virtual squarePegOperation() { blah } } class RoundPeg { public: void virtual roundPegOperation() { blah } } UNIT-III

  13. L1 Adapting Local Classes to RMI • Comparison: • Increases reusability of local class • Improves performance of local class • Doesn't use Java single parent by subclassing (uses composition) UNIT-III

  14. L1 Related Patterns • Adapter can be similar to the remote form of Proxy. However, Proxy doesn't change interfaces. • Decorator enhances another object without changing its interface. • Bridge similar structure to Adapter, but different intent. Separates interface from implementation. UNIT-III

  15. L1 Conclusions • Allows collaboration between classes with incompatible interfaces • Implemented in either class-based (inheritance) or object-based (composition & delegation) manner • Useful pattern which promotes reuse and allows integration of diverse software components UNIT-III

  16. L1 Adapter • You have • legacy code • current client • Adapter changes interface of legacy code so client can use it • Adapter fills the gap b/w two interfaces • No changes needed for either • legacy code, or • client UNIT-III

  17. L1 Adapter (cont.) class NewTime { public: int GetTime() { return m_oldtime.get_time() * 1000 + 8; } private: OldTime m_oldtime; }; UNIT-III

  18. L2 The Bridge Pattern UNIT-III

  19. L2 Overview • Intent • Also Known As • Motivation • Participants • Structure • Applicability • Benefits • Drawbacks • Related Pattern I UNIT-III

  20. L2 BRIDGE (Object Structural) • Intent: Decouple as abstraction from its implementation so that the two can vary independently. • Also Known As: Handle/Body UNIT-III

  21. Entry oracleDBEntry FilesysEntry L2 Motivation UNIT-III

  22. Entry Appointment Task OracleDBApp. FilesysApp. OracleDBTask FilesysTask L2 Motivation UNIT-III

  23. Task getPriority() setPriority() getText() setText() Destroy() Appointment getAlarm() setAlarm() getText() setText() Destroy() PersistentImp. initialize() store() load() Destroy() Entry getText() setText() Destroy() impl Bridge OraclePImp initialize() store() load() destroy() AccessPImp initialize() store() load() destroy() L2 Motivation UNIT-III

  24. L2 Participants • Abstraction (Entry): • - define the abstraction’s interface • - maintains a reference to an object of type • Implementor • Refined Abstraction (Task): • - extends the interface defined by Abstraction UNIT-III

  25. L2 Participants (continue) • Implementor (persistentImp): • - defines an interface for implementation • classes. Typically, this Implementor’s • interface provides only primitive menthod • ConcreteImplementor (oraclePImp, AccessPImp): • - implements the Implementor’s interface UNIT-III

  26. Client Implementer Abstraction impl OperationImp() ConcreteImplementerB RefinedAbstraction ConcreteImplementerA L2 Structure UNIT-III

  27. L2 Applicability • Want toavoid a permanent binding between an abstraction and implementation. • When abstractions and implementations should be extensible through subclassing. • When implementation changes should not impact clients. UNIT-III

  28. L2 Applicability (continue) • When the implementation should be completely hidden from the client. (C++) • When you have a proliferation of classes. • When, unknown to the client, implementations are shared among objects. UNIT-III

  29. L2 Benefits • Avoid permanent binding between an abstraction and its implementation • Avoid nested generalizations • Ease adding new implementations • Reduce code repetition • Allow runtime switching of behavior UNIT-III

  30. L2 Drawbacks • Double indirection • - “entry”operation are implemented by subclasses ofPersistentImp class. Entryclass must delegate the message to a PersistentImp subclass which implements the appropriate method. This will have a slight impact on performance. UNIT-III

  31. L2 Composite Pattern • Intent : Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. UNIT-III

  32. L2 Consequences • decoupling interface & implementation - implementation of abstraction - can be configured at run-time - eliminate compile time dependencies on implementation - encourages layering • improved extensibility - Abstraction & Implementer - can be extended independently • hiding implementation details from clients UNIT-III

  33. L3 Composite Pattern • Facilitates the composition of objects into tree structures that represent part-whole hierarchies. • These hierarchies consist of both primitive and composite objects. UNIT-III

  34. L3 UNIT-III

  35. L3 Observations • The Component (Graphic) is an abstract class that declares the interface for the objects in the pattern. As the interface, it declares methods (such as Draw) that are specific to the graphical objects. • Line, Rectangle, and Text are so-called Leafs, which are subclasses that implement Draw to draw lines, rectangles, and text, respectively. UNIT-III

  36. L3 Observations (Continued) • The Picture class represents a number of graphics objects. It can call Draw on its children and also uses children to compose pictures using primitive objects. UNIT-III

  37. Concluding Considerations L3 • The Composite Pattern is used to represent part-whole object hierarchies. • Clients interact with objects through the component class. • It enables clients to to ignore the specifics of which leaf or composite class they use. • Can be used recursively, so that Display can show both flares and stars. • New components can easily be added to a design. UNIT-III

  38. L4 BRIDGE (Object Structural) • Intent: Decouple as abstraction from its implementation so that the two can vary independently. • Also Known As: Handle/Body UNIT-III

  39. Entry oracleDBEntry FilesysEntry L4 Motivation UNIT-III

  40. Entry Appointment Task OracleDBApp. FilesysApp. OracleDBTask FilesysTask L4 Motivation UNIT-III

  41. L5 Two-way Adapters class PegAdapter: public SquarePeg, RoundPeg { public: void virtual roundPegOperation() { add some corners; squarePegOperation(); } void virtual squarePegOperation() { add some corners; roundPegOperation(); } } class SquarePeg { public: void virtual squarePegOperation() { blah } } class RoundPeg { public: void virtual roundPegOperation() { blah } } UNIT-III

  42. L5 Adapting Local Classes to RMI • Comparison: • Increases reusability of local class • Improves performance of local class • Doesn't use Java single parent by subclassing (uses composition) UNIT-III

  43. Task getPriority() setPriority() getText() setText() Destroy() Appointment getAlarm() setAlarm() getText() setText() Destroy() PersistentImp. initialize() store() load() Destroy() Entry getText() setText() Destroy() impl Bridge OraclePImp initialize() store() load() destroy() AccessPImp initialize() store() load() destroy() L6 Motivation UNIT-III

  44. L6 Participants • Abstraction (Entry): • - define the abstraction’s interface • - maintains a reference to an object of type • Implementor • Refined Abstraction (Task): • - extends the interface defined by Abstraction UNIT-III

  45. L7 References • Becker, Dan. Design networked applications in RMI using the Adapter design pattern. JavaWorld Magazine, May 1999. http://www.javaworld.com/javaworld/jw-05-1999/jw-05-networked.html • Buschmann et al. A System of Patterns: Pattern-Oriented Software Architecture. John Wiley and Sons. Chichester. 1996 • Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. Boston. 1995 • Nguyen, D.X. Tutorial 10: Stacks and Queues: The Adapter Pattern. Rice University. 1999. http://www.owlnet.rice.edu/~comp212/99-fall/tutorials/10/tutorial10.html • Whitney, Roger. CS 635 Advanced Object-Oriented Design & Programming. San Diego State University. 2001. http://www.eli.sdsu.edu/courses/spring01/cs635/notes/proxy/proxy.html#Heading10 • Shalloway, Alan., and Trott, James R., Design Patterns Explained: A New Perspective on Object-Oriented Design, Addison-Wesley, 2002. • Rising, Linda., The Patterns Handbook: Techniques, Strategies, and Applications, Cambridge university Press, 1998. UNIT-III

More Related