I will today focus on another trend that I am particularly interested on: Component-Based Development, also known as Component-Based Software Engineering (CBSE). Conventional wisdom says:

“Component-Based Development (CBD) claims to offer a radically new approach to the design, construction, implementation and evolution of software applications. Software applications are assembled from components from a variety of sources; the components themselves may be written in several different programming languages and run on several different platforms.”

Although CBD is normally associated with heterogeneous development (different sources and/or programming languages), I personally think that CBD is also useful within a closed environment.

For instance, CBD enforces a better organization of your application features. Does your application manipulate files? So, create a file-manipulation component! Obvious? Not quite.

It takes additional effort to write a software component that is truly reusable. The component needs:

- additional testing
- robust input validity checking
- to return useful error messages as necessary
- to be fully documented

Szyperski and Messerschmitt claim that a component should:

- Have multiple uses
- Not be context-specific
- Be composable with other components
- Be encapsulated : Only its interface is exposed
- Be independently deployed and versioned

I am yet to find a software component technology that fulfils my own requirements: A lean and mean arquitecture that allows any developer to better organize and reuse his/her own development efforts.

That’s why I am developing my own lightweight component arquitecture! I plan to incrementally describe a specify it on this blog on the following weeks. Stay tuned.