A while ago I was reading June's edition of ACM Queue (late again!), which is devoted to Software Components and Component Technologies. It's been a fairly interesting reading, though much of it is not new for those familiar with the evolution and concepts behind COM, Java, EJB, .NET and other component technologies.
One interesting aspect I did find is that, by and large, the focus on what a component actually is (the definition) still revolves mainly about Component Reuse and Integration/Coupling. While this is fine, my personal opinion is that these are not the most important properties or benefits of software components and (as much as I dislike the term) Component-Oriented software architectures.
To me the key property that makes the concept of "Component" work is that of Composability [1]: being able to create software applications (which might very well be components in and of themselves) from components. For me it is this composability property (or objective, if you will) from which the benefits of software components are derived.
Take Component reuse for example: A component is only reusable if a) it solves a well defined need (or domain) that is valuable and b) it is easily composable with other components. Only if you design a component for composability do you end up with loose coupling and good interfaces to the component.
Composability is by far a more interesting property of components than reuse. Composability by itself brings a lot of good properties to your software applications and components, that you will want to strive for even if reusability doesn't happen. In other words, achieving composability is a worthwhile goal that will improve your sofware design even if reusability is not your main concern or if it is simply of no value at that moment.
One key benefit of embracing Inversion of Control (IoC) and Dependency Injection patterns as key patterns in application architecture is that they very much favor and make it much easier to design your software out of composable components. IoC does not guarantee loose coupling but it does make it more likely to happen, but, more importantly, it helps you ensure that your individual components making your application are more cleanly connected together through well-defined interfaces and a robust interaction model.
Notice that this does not mean that those individual components will be more reusable (they might be, but not necessarily). In fact, those individual components might very well be pretty specific to your application or application domain. However, by approaching their design from a composability point of view, you provide a clean path to replace them if the need arises. The application of design patterns such as this will slowly, but surely, lead you to a better application architecture and a more sound component design that might increase your chances of reducing coupling and even creating reusable components, even if that was not your original intent.
Part of the problem of approaching the component problem from the reuse perspective is that it can [mis-]lead you easily into the realm of "what-if" component development. That is, creating components for hypothetical and "likely" scenarios that might not be used right away (or ever at all), and that will certainly increase the complexity of your software, probably needlessly (and if there's an astronaut architect around, watch out!). Now, for some kinds of software (notably companies that build reusable components such as UI controls and the like), this is a kind of necessary evil, but for everyone else, it can increase your chances of failing.
Approaching this problem from the composability perspective, however, has no such risk associated, since this is a property that will only affect your software structure. Instead of forcing you to focus on reuse, it will focus you on the real properties that matter regarding abstraction levels, decoupling external systems and the like. Done right, basing your software on this principles can yield a substantial reward in how maintainable it is and how tightly bound chances are when indeed problem arises.
[1] one of the few articles I've seen where composability is directly approach is "Composability for Software Components: An Approach Based on the Whole Part Theory", by Franck Barbier.
