cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: over-componentization scenario
Date Wed, 01 Oct 2003 13:05:16 GMT

On Wednesday, Oct 1, 2003, at 13:36 Europe/Rome, Stephen McConnell 

> As a matter of principal - I have to make a comment here.
> There are assertion onf the Cocoon web site that imply some evil 
> associated with "over componentization".  I would like to take you up 
> on this.  Now - to give fair warning - I have specific ideas about 
> what is and what is not a component.  And I'm thinking in my mind that 
> over-componentization of good components is a null-event .. it does 
> not exist. However, I am trying to rationalize this with you 
> assertions .  Can you help me out here?  I can confirm that I am an 
> avid non-component developer - when appropriate - however - in my mind 
> there is a definative point where something is a component as distict 
> from an implementation object.  That difinative point concerns 
> publication and containment (in my view of the world).
> What I would like to know is what (in you view of the world) 
> constitues an over-componentization scenario?

when you use a component and a simple regular class would have been 
exactly as functional, easier to understand, future compatible.

over-componentization is an instance of over-design.

I was a big fan of early-on interface creation. I'm not anymore. I now 
believe in incremental programming, darwinistic, you could say: change 
things only when a need for change emerges.

or, to use XP terminology, "do the simplest thing that can possibly 

An example of overcomponentization in cocoon: the cache as a SAX 
compilation strategy, the strategy could be pluggable, therefore, let's 
create a sax compiler component and an interface that describes it.

After years, nobody ever implemented another instance of that 
component. Componentization was not created by a real-life need, but it 
was created by design elegance. This is, IMO, bad practice.

Since real-life needs are measurable, while design elegance is not, I 
think the first is a much healthier driver for innovation, and, 
moreover, results in less code to write, more readable code and simpler 

Note, however, that there are places, in cocoon, where components *DO* 
make sense (sitemap components, for example, where polymorphic behavior 
is required by clear real-life needs!), but many components might be 
replaced with regular classes with no lack of functionality.

Now, at the same time, incremental thinking suggests to start patching 
only when a problem emerges and 'de-componentize' something is, again, 
an elegance-driven concept, if the real need doesn't emerge.

So, right now, we are all set.... but if somebody has a problem with 
how the componentization is done in cocoon and has a better solution 
and does the patch, I'll be glad to see it applied.


View raw message