COTS%20Challenges%20for%20%20Embedded%20Systems

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_at_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 AA()
pImpl new A_Impl Afoo()
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
ltltinvokegtgt
Client
service()

ltltinstantiatesgtgt
Defines a concrete interface for a particular
role. Also gives access to root capabilities.
Component Factory
create() find()
Component
ltltnewgtgt
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
Component
Extension 2
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

• Microsofts 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_pro
  gramming
• Aspect-Oriented Programming (AOP)
• https//en.wikipedia.org/wiki/Aspect-oriented_prog
  ramming