Component Based Programming

The writing is on the wall:

Object Magazine changed their name to Component Strategies.
Articles in trade magazines are touting components as the new SilverBullet.
EJB is now the official OMG middleware technology.
VB and COM are more popular than ever.
Every major Java development product (IDEs, Application Servers, etc) are advertising about building software by just wiring together components.
Software development is still hard and OO becomes the new scapegoat.

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:

They get the job done (faster development too).
They are deployed in the real world.
They are fairly safe and reliable (when well tested).
Less and less code need to be written these days. (Reusability!)
Plug-and-play systems are easy to modify (gross functionality).

Some potential losses:

The end user gets an approximation of the solution.
We trade off performance.
We trade off usability (the screens were autogenerated by the component!)
We lose the craft of programming. No we don't. Someone has to build those components in the first place. Strangely, many clients feel that the components they paid for in some sense belong to them, so when the next client comes along one has to build some more similar but not identical ones, and so on. There are things that are more fun than this sort of repetition, but the craft will continue to matter. Publicly available components need even more craft.
Software development becomes and automated, soulless factory production-line endeavour.

-- 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:

One can create OpenSource ActiveX components. However, OpenSource GUI components for Windows that do not talk ActiveX would not be as successful.
The GNOME project is developing a component framework for embedding and linking objects that is completely OpenSource.
There are many OpenSource JavaBean components, as well as many ClosedSource beans.
The TheHalloweenDocument from Microsoft identifies intercomponent protocols as the strength of OpenSource software, and the best point of attack for Microsoft's to compete against the OpenSource movement.

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: http://www.componentsoftware.org/cgi-bin/wiki.pl?ComponentInternals Hope you all find it interesting, and can give me feedback. Thanks. -- http://www.componentsoftware.org/cgi-bin/wiki.pl?JianyingJi

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).

CategoryComponents