I’ve been getting into components with a whole new passion than I had in the past, but when I talk to other geeks about it, they have some misunderstanding about this technology. So, I thought that I would jot down my thoughts on the subject.

Back in the old days, I made sure that all of my utility programs and shell scripts observed a particular functionality level so that the program would have more use than this “one particular time.” The most important of these was reading data from stdin and output to stdout … then it could play nicely in a Unix command line pipe sequence. Each of these “components” lived in my “bin” directory and were something that with proper documentation became functionality that I could use over again.

To a certain degree, things haven’t changed much … well, they shouldn’t have changed.

When I need some functionality to one of my applications, instead of just jumping into it, I stop and think about putting together a reusable component. It is the same “stop and think” habit I do in order to make unit tests.

What is a Component?

The term “component” (while part of every person’s nomenclature) has a specific technical meaning in the world of software engineering. Yes, it is similar to the fact that “objects” has both an everyday meaning and a technical one.

This brings up another point: objects are not components. Anyone who originally got into object-oriented programming with the vision of reusable objects quickly became disappointed. The main difference between the two are that components are reusable and objects are generally not.

Why not? I’ve come up with three criteria that makes a component reusable and that makes CBD different from OOP:

Components are Replaceable

The technical definition of component is not far from its generally accepted one. A component is a “replaceable part of a system.” For instance, a screw is replaceable with other screws because there is a generally accepted specification that details the screw width, the thread separation, etc.

So a component should have a well-defined, published interface into it and out of it. Out of it? Yes, we have all used APIs to call functions or object methods, but there is a way to make “calls out of a component independent as well.

The technique that requires the least amount of resources is to send events. If each of your components send an event for anything that comes out, then it allows you to swap components in and out. Events end up as nothing more than a function call so it isn’t that much slower.

This capability of swapping components actually brings up another point …

Components are Independent

The primary reason why the OOP software industry has not seen the promises of resuse realized has a lot to do with the way we program. Let’s suppose we have a class that has some functionality that we want to use in another program. We copy the code over and attempt to compile it, but it fails because it has some dependency on two other classes (not to mention its entire ancestral tree). So we grab those two classes, but each of those has dependencies on more classes … soon, you’ve basically copied your entire application over to the new one. Not very reusable.

If you build your technology into components with all dependencies encapsulated, then it becomes much easier to reuse.

Of course, there is the issue of balancing this independence with the weight of the component. I mean, you don’t want to have to duplicate an XML library within your component. This balance will vary from project to project, but all dependencies must be clearly published (and easily retrieved) in order to make reusability happen.

Here’s a good example. I wrote a component to access my database, and I was taught by a number of OOP book to create a class that does the access, and this class populates another class to pass back to the caller. I never stopped to think about it, but not only does the caller need to program against this second class, but for every row of the database query, we are creating, populating, accessing and then tearing down a new class. Not very efficient.

A better option would be to have the original class fill in the values in properties and have those properties change every time the caller asks for the next row. Now the caller is just dealing with primitives and strings instead of with specialized class.

Components are Black Boxes

Components can be integrated or assembled without source code. This black box approach is called third-party composition by Szyperski. So along with documenting the component, it must be able to be integrated after the fact. This obviously requires some framework to work within, since most programs can not call a function (or object method) without access to the source.

I’m partial to Java, and within that world, the Java Bean standard gives you this feature. Java, by being partly compiled means that it is quite easy to have this “late binding” and “loose coupling” of components. This Java Bean specification also allows you to build a components without the need for the source.

My conclusion? Well, this is fundamentally a blog, and you don’t have to have any conclusion to one’s postings … but I would like to see the Java Bean world come back … not to its previous level of hype (see my previous posting), but to a mature level of software reuse.