1 / 15

E81 CSE 532S: Advanced Multi-Paradigm Software Development

The Extension Interface Pattern allows for the extension and modification of a component's functionality without breaking existing client code. It provides a way to export multiple interfaces based on the roles a component plays, preventing interface bloating and enabling versioning. This pattern promotes extensibility, separation of concerns, and behavioral consistency.

davidkane
Download Presentation

E81 CSE 532S: Advanced Multi-Paradigm Software Development

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. E81 CSE 532S: Advanced Multi-Paradigm Software Development Extension Interface Pattern Venkita Subramonian, Christopher Gill, Huang-Ming Huang, Shih-Ling Chen, Sajeeva Pallemulle Department of Computer Science and Engineering Washington University, St. Louis cdgill@cse.wustl.edu

  2. Handle/Body Idiom (Bridge Pattern) pImpl – Pointer to Implementation class A_Impl; class A { public: void foo() private: A_Impl *pImpl; }; #include “A.h” #include “A_Impl.h” A::A() { pImpl = new A_Impl; } A::foo() { } A.cpp A.h Client code does not have to be recompiled even if A_Impl.h changes ACE_Reactor ACE_Reactor_Impl ACE_Select_Reactor_Impl ACE_WFMO_Reactor_Impl

  3. Limitation: Interface Changes • Does pImpl help with interface changes? class A_Impl; class A { public: void foo(); void bar(); private: A_Impl *pImpl; }; class A_Impl; class A { public: void foo() private: A_Impl *pImpl; }; A.h • Answer - No

  4. Extending Functionality • Add methods to the existing interfaces • Pros: • Simple, most languages support this • Cons: • Bloated interfaces • Client recompilation class A { public: void foo(); void bar(); }; class A { public: void foo(); };

  5. Extending Functionality (continued) • Multiple inheritance of new interfaces • Pros: • Well known “mixin” approach (also class form of Adapter pattern) • Flexible • Cons: • Proliferation of subclasses with lots of roles • Versioning is difficult class A2 { public: void bar(); }; class A_Impl : public A, public A2 { }; class A { public: void foo(); }; class A_Impl : public A { };

  6. Extending Functionality (continued) • Decorator • Pros: • Run-time extensibility • Cons: • Client must explicitly track different interfaces • Visitor • Pros: • Flexible addition of new roles • Cons: • Hard to attach new state to component, add components • Need fixed component class hierarchy

  7. Intent of the Extension Interface Pattern • Extending or Modifying the functionality of a component. • Allows multiple interfaces to be exported by a component • Each corresponds to a role the component plays • Prevents bloating of interfaces • Roles are at least partly disjoint • Common case: each role narrower than union of roles • Prevents breaking existing client code • Allows versioning of interfaces Component Interface1 Interface2 Interface3

  8. Design Forces • Do not break existing client code • Backward compatibility • Behavioral consistency • No client recompilation required • Minimize changes to existing component code • Location, language, etc. transparency

  9. Solution • Separate interfaces by roles • Clients use role-appropriate interfaces • Must support at least one interface • Always have access to a “root” interface • All provided interfaces are accessible • Can iterate through interfaces dynamically • Export new interfaces by addition to set • Without changing existing ones

  10. Structure • Defines a meta-interface - functionality each interface must support Root Interface • Accesses factories to create components. Uses extension interfaces to access component functionality getExtension() Extension Interface <<invoke>> Client service() * <<instantiates>> Defines a concrete interface for a particular role. Also gives access to root capabilities. Component Factory create() find() Component <<new>> service() • Implement interfaces for creating components. (optional) also, interfaces for locating components • Play different roles. Provide extension interfaces • Return initial interface to component factory

  11. Versioning Variant (COM Approach) • Published interface cannot be changed. • Once published, an interface is a contract • Add new interface instead of changing existing one • Aggregation is used to emulate inheritance • An object can offer the interfaces of base object

  12. Dynamics : Factory : Client : Extension 2 : Component : Extension 1 CreateInstance(Ext.Intf. 1) new create Ref. To Extension1 service_1 QueryInterface(Extension Interface 2) create Ref. To Extension2

  13. Design Considerations • Benefits • Extensibility • Separation of concerns • Polymorphism • Decoupling of components and their clients • Support for interface aggregation and delegation • Liabilities • Increased component design and implementation effort • Increased client programming complexity • Additional indirection and run-time overhead

  14. Known uses • Microsoft’s COM/COM+ • CORBA 3 • OpenDoc • Administrator dashboards • For example consider lab 3 assignment • Instead of interacting only with Producer, user (or administrator) could interact with any Producer, Director, or Player • Could dynamically query and collect interfaces and then tie them into producer-like menu-based interfaces

  15. Related Paradigms • Subject-Oriented Programming (SOP) https://en.wikipedia.org/wiki/Subject-oriented_programming • Aspect-Oriented Programming (AOP) https://en.wikipedia.org/wiki/Aspect-oriented_programming

More Related