Component Based Programming

The writing is on the wall:

ComponentBasedProgramming is here. But, how much is hype and how much real?

CaseTools are back stronger than ever. Now they don't generate the application, but they generate the glue to tie your components together.

Some Component things that seem to be winning:

Some potential losses: -- ToddCoram
See also BlackBoxComponentry
I think it's a fad, another grasp at the golden ring, the SilverBullet. ReuseWithoutSource? is very hard to achieve, but the ClosedSource model of development that most of the industry is stuck on precludes the much more successful model, ReuseWithSource?. ComponentBasedProgramming attempts to generate tighter and better documented contracts so that the reuser can have some idea of what to expect from the component. The idea is to reduce the TrialAndError programming normally needed, in the absence of source, to figure out how the reused code actually works. This fails to deliver, because every bug encountered still requires TrialAndErrorProgramming to understand its extent and divine its workaround. ReuseWithSource? is much easier - where the documentation fails, you can look at the code, and you have the choice to fix bugs.

The point about the value of source code is a good one, but this misses the point of Component based programming, which is to defines a-priori protocols between components, not just between components and the programmer using those components. This allows the development of a component marketplace, in which components from different vendors can work together. Thus, one can buy off-the-shelf ActiveX components or JavaBeans from different vendors and plug them together into applications.

That is the theory behind BlackBoxComponentry, is proven to work for hardware and probably is competitive in certain well codified domains of software (like money management). But the boundary free technique of ReuseWithSource? can make all the difference in a time-critical endeavour with budget constraints. Businesses that can fix things themselves (instead of relying on 3rd party component developers) can have a competitive advantage in certain markets for software services.

The approaches of ComponentBasedDevelopment and OpenSource are orthogonal not competing. You need a component-based approach to allow different vendors to write components that will interwork according to well defined protocols. However, there is a big advantage if those components are also open source, because it is possible for the user of those components to find and fix bugs in their implementation.

Component based programming is the bedrock of OpenSource development. The success of OpenSource depends on the use of open, simple inter-component protocols, such as the Internet protocols, XML, HTML, HTTP, CORBA GIOP, etc. Thus, each project individually has a small scope, and so can be managed despite geographically and temporally distributed teams. But by combining components, their usefulness is greatly increased.

For example:

Of course, components do not have to be distributed, or visual. For my money, the UnixShell is the most successful component based development environment yet. All the commands have a uniform (ish) interface between themselves, and the shell provides the glue logic.

Aren't CICS/IMS transactions reusable ComponentBasedProgramming?

ComponentBasedProgramming is described by some as the next layer above ObjectOrientedProgramming. To me, it means thinking about software design (usually DistributedSoftware?) in terms of services (a service or services provided by a component) and the communication between the services. I think EnterpriseJavaBeans are a good tool for doing component based programming. -- ColJac
What I see as the most interesting feature, and goal, of component based programming, (especially BlackBoxComponentry) is the ability of at run time to reconfigure and replace components, which is something that non-component based solutions can't support. Components also through modularity, can support very detailed logging for debugging, without the need of INT3. Of course, like any other methodology, there needs to be discipline, or else bloating will result. To borrow a term from modular programming, refactor mercilessly.

To develop my thoughts more fully, I am currently in the process of implementing a component system kernel, if you will. I am laying out my ideas and resources on the following wiki: Hope you all find it interesting, and can give me feedback. Thanks. --

BorlandDelphi, ComponentPascal/Oberon, and Lazarus have used components for quite some time. It can be somewhat like Lego development when one needs to quickly create GUI especially. Components are heavily related with Object Oriented and Modular Programming. One can still use components and mix in non-object oriented programming and database programming though. If there is any hype out there about a brand new component oriented paradigm, remember that some development IDE's and languages have been using components for some time now (it is not a brand new idea).

EditText of this page (last edited November 30, 2010) or FindPage with title or text search