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