One topic that has continued to bother me is the idea of “components”. I’ve seen books published on the topic, I’ve also seen groups formed to research the topic (i.e. IBM Research had a group that studied components, its the same group that implemented SOAP). What bothers me is that it seems like that there doesn’t seem to be a concrete definition, in fact it looks like a restricted form of OOP. I also hate the use of the word “component” since it gives the impression that these are different things than objects, a more appropriate word would be ”plugin”.
Well, Ted Neward writes about his definition of what is a component:
The object “failure”, inasmuch as it was a failure, could be attributed to two core problems, among others: first, the initial belief that the key to reuse in an object system lay through inheriting implementation from base classes, and second, the fact that objects are simply too granular, too fine-grained to reuse effectively.
Well I don’t agree with the conclusion. The absence of inheritance doesn’t define a component. The granularity also doesn’t since it’s a completely qualitative criteria.
Let me therefore make my own more generalized observations. Plugins (i.e. Components) have several characteristics.
1. A mechanism for dynamic extensions, this may cover delegation, event handlers or even inheritance (see SOM).
2. A mechanism of encapsulation that can be dynamically introspected. In otherwords, all plugins have a way of describing to the outside world what its interface looks like. The reason why COM or XPCOM were invented is that C and C++ have no way of describing this information dynamically.
3 . Finally, my controversial and highly speculative addition. A restriction on attributes to that of value types. In otherwords, the Law of Demeter cannot be violated. Attributes other than value types should be of the kind found in (1), that is a means of extension.
Actually, this reminded me, there’s a good book Server Component Patterns that covers a pattern language for components. I haven’t read the book, however, its obvious that you can’t define a Plugin without defining the container its supposed to work in. So to complete the list:
4. A defined lifecycle that conforms to the requirements of container that uses the plugin.
5. A protocol for interacting with the container. This covers, how to find other components and their factories, how to reference and invoke other components, etc. In otherwords, the functionality you have for POJOs used in the context of the container.
Now, I’m intrigued, the Eclipse Plugin model in an extremely advanced component model that goes beyond just properties and events of the JavaBeans component model. In fact, there is an ongoing project called Equinox that is researching this very topic.