E81 CSE 532S: Advanced Multi-Paradigm Software Development

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