E81 CSE 532S: Advanced Multi-Paradigm Software Development Venkita Subramonian, Christopher Gill, Huang-Ming Huang, Shih-Ling Chen, Sajeeva Pallemulle Department of Computer Science and Engineering Washington University, St. Louis Extension Interface Pattern

Handle/Body Idiom (Bridge Pattern) ACE_Reactor ACE_Reactor_Impl ACE_Select_Reactor_ImplACE_WFMO_Reactor_Impl 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.h A.cpp Client code does not have to be recompiled even if A_Impl.h changes

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

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(); };

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 { };

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

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

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

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

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

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

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

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

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

Related Paradigms Subject-Oriented Programming (SOP) oriented_programming Aspect-Oriented Programming (AOP) oriented_programming