Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Wed, 1 Oct 2003 15:05:16 +0200
Subject: Re: over-componentization scenario
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Stefano Mazzocchi <stefano@apache.org>
To: dev@cocoon.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F7ABC24.5080508@apache.org>
Message-Id: <E6B07B14-F40F-11D7-AD24-000393D2CB02@apache.org>


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

> 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 
work".

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 
systems.

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.

--
Stefano.