Random musings from my awakening dementia...
08.11.2003  
Component Definition ... Continued
 

I'm quite interested in the concept of software components and how those ideas can be applied to Java code. Thoughts or ideas I have on this subject get dropped here for the benefit of humanity and my own hubris.

© 2003-2005, Howard Abrams



Except where otherwise noted, all original content is licensed under a Creative Commons License.
See details.

Following up on my previous thoughts on the nature of software components, I came across a very succinct definition in UML Components: A Simple Process for Specifying Component-Based Software by John Cheesman and John Daniels.

They begin by listing the three “fundamental principles that underpin object technology” …

  1. Unification of data and function
  2. Encapsulation
  3. Identify

The relationship between OOP and CBD is close, and I liked the fact that their definition of components just builds upon what most programmers are familiar with:

Components extend these object principles by elaborating the notion of an object specification with an explicit representation of specification dependency called an interface …

To summarize: Component-based development is different from previous approaches in its separation of component specification from implementation, and in the division of component specifications into interfaces.

But doesn’t all OOP languages have interfaces? Yes, but think of the situation if every part of your application only talked to every other piece through well-defined interfaces. Each piece that implemented these interfaces then becomes replaceable . If each piece is replaceable, then I can see the following two impacts:

  1. Each replaceable piece can now be upgraded without impact to other components. Just because you replace your car’s window wipers doesn’t mean you need to test that the car door opens. Well, you probably would test that just by getting in, but you get my point.
  1. Each replaceable piece is a black box, and is now reusable. Going through the exercise of designing interfaces and thinking about these relationships mean you’ve defined the dependencies, such that it can now be independent.

In most component architectures, you can upgrade these interfaces, but you may have to think carefully about the process. You should be able to add new methods as long as you don’t remove methods.

I still maintain that as many calls “out” from isolated black-box components should be done via events, but without the help of component assembly tools, this is quite a challenge.