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.
