|
|
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.
|
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” …
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 … 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:
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. Thought originally posted on Monday, 11 August 2003
© 2003-2005, Howard Abrams • Except where otherwise noted, all original content is licensed under a Creative Commons License (see details). |
|||||||||||
|
||||||||||||