A little bit more than a couple of years ago Component Oriented Design was all the rage. Beyond Object Oriented Programming they said… For about a month.

The fine print, of course, mentioned that Components were not there to replace OOP, more like complement it.

I guess the books didn’t sell very well and as a result you hardly ever hear anyone mentioning Components these days.

Truth of the matter is, Components have always been there as an integral ingredient of OO. Because, if we ignore the attributes that were attached to them a few years ago to feed book pages (call me Web Services, Distributed, etc), a Component is essentially a bunch of Classes collaborating inside their little cosmos and communicating with the rest of the world through a narrow interface.

In its simplest form, say, a Java component, is some code in a package.

Writing a component is easy, provided we keep one simple rule in mind. The world is oblivious to what happens inside the component. The world is only interested in what the component can provide it with and what the component needs to perform its task. In other words, the world should only care calling the methods of a Component’s public Interface.

‘All this sounds so simple and basic and everybody knows about it since school…’ I can imagine you saying and a fair claim it is.

So why doesn’t anyone do it?

Blame whoever you want, but today’s Java development has reached a point where access levels, packages and interfaces have completely lost their meaning.

Here’s a few rules of thumb you might want to consider for designing more effectively:

Start by giving every new Class package level access instead of making it public. Same goes for non-private methods.

Don’t give private methods default access just to unit test them. Use reflection instead.

Do not give every class an Interface. Contrary to popular belief, Interfaces are not there to accommodate auto-wired Dependency Injection.

Create packages based on their Domain identity, not their type of functionality. For example, do com.universe.solarsystem.services and com.universe.solarsystem.dao instead of com.universe.services.solarsystem and com.universe.dao.solarsystem.

Treat packages (Components) they same way you treat classes. Decompose them based on responsibilities and make them remember to tell, don’t ask.

There’s an ancient OO paradigm called Encapsulation and it goes beyond Classes. Hide your Component’s internals and only expose what’s needed. Collaborators don’t care how the Component performs its magic.

In the vast majority of cases, it makes more sense to make code specific, instead of generic. Think of the small picture, then the bigger picture and then fit those in the Big Picture.

Get the basics right before you leverage the framework. And choose frameworks in a way that will suit your design instead of basing your design on Frameworks.

This entry was posted on Sunday, September 10th, 2006 at 2:41 pm and is filed under Software. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.