Connection Points
Connection PointsPhilipEskelin: Using COM as a solution for connecting components, connection points can be used to employ the Observer pattern between a client (a.k.a. sink or observer) and a connectable object (a.k.a. source or observable). IConnectionPointContainer holds connection points in the connectable object. The client registers with the connectable object, passing an interface ID for an interface it implements that is called by the object when ...
I like this approach. In the world of COM, connection points work this way. The client (the observer)numerates "connection points" in a "connection point container" inside a connectable COM object (the subject) to see which one it's interested in. When it gets to the right connection point, it calls IConnectionPoint::Advise method (registers with the subject) and passes a pointer to an "outgoing interface" that the connectable object's IConnection point implementation calls when appropriate. Multiple clients can attach themselves to a single connection point.
When the object decides to multicast (nofity) via connection points to all advisable clients, it enumerates through each outgoing interface given by each client and calls the equivalent of its update method. When done receiving notifications, the client calls IConnectionPoint::Unadvise (unregisters with the subject).
Actually, for clarity, I lied. The IConnectionPoint interface implemented by the connectable object acts as the *real* subject, and the outgoing interface acts as the *real* observer. Each object implements its part of the deal.
Avoid being stoned for being too Microsoft-specific, JavaBeans has an events concept that allows for similar behavior. Constrained and Bound properties are specializations of this. These concepts are covered in the ComponentDesignPatterns project.
NatPryce: This shows how there are multiple ways that components need to communicate. Each of these is an Abstract Interaction that is encoded by the framework designer.
The REX and Darwin/Regis [1] and Regent [2] systems make this explicit in the component model. A component's interface was made up of "interaction objects" rather than being an object-oriented interface of polymorphic methods. Each interaction object encapsulated a role in an Abstract Interaction and messages could flow both into and out of an interaction object. Thus request/reply transactions, Observer style event announcement, asynchronous message sending, rendezvous and any other Abstract Interaction are unified into a single interface model.
I am developing an IDL-like language for specifying these interaction styles and generating the interaction objects and distribution support.
PhilipEskelin: Cool Nat. The more I think about this the more I see that ComponentFramework could be a name we could use for a subsection of our language that contains LayeredFrameworks and AbstractInteractions. AbstractInteractions can manifest itself in the context of a framework and components via:
NatPryce: I agree. The framework is there to support connection and mediation between components and provides ComponentGlue.
However, Template Method is really to do with the implementation of concrete component types, rather than abstract protocols that components can take part in. In particular, Template Method requires the use of inheritance, but most component frameworks emphasize delagation and composition and reduce the use of inheritance. For example, how would one use Template Method with COM objects? I don't think one can; instead one would define an abstract interaction protocol between two components, one of which acts as a Strategy for the other. In other words, Strategy is the component-based equivalent to (replacement of) Template Method. Does that make sense?
Related:
EditText of this page
(last edited October 1, 2011)
or FindPage with title or text search