The reason WHY OO sucks

[Peter-Henry Mander]

Hi guys,

At least I'm not the only one working on a Sunday, I don't feel so 
isolated! (-:

I can only voice my support for this being an excellent example of OO 
design issues that cause huge fisticuffs among programmers. It gets 
worse as you try to create abstract patterns of such.

Maybe someone will suggest using the Visitor pattern, where the 
"ShearWool" object visits all "Sheep" instances in the "Flock" object in 
turn accumulating the "Wool" instances from each. It is counterintuitive 
though, since each "Sheep" needs to call the "visit" method on 
"ShearWool" passing a reference to self and I don't think that reflects 
reality (self shearing sheep!) Besides, "Shepherd" instance would have a 
hard time justifying its existance, especially being a drunk too.

It disassociates the classes fairly nicely though, now the shepherd can 
delegate shearing to his "Dog", sorry, "Visitor" instance and get 
irresponsibly pissed at the local brewer, but it does require the 
designer to know the pattern, and anyone reading the code too.

Pete.

Wiger Ulf wrote:
> On June 15 2003, "Dr.Dr.Ruediger M.Flaig" wrote:
> 
> 
>>In OO, it is often pretty difficult to decide where to attach a
>>method which is not tied to an object by logical necessity;
>>and when there is a pyramid of objects always appearing 
>>together, shall we attach a method to the higher components 
>>(wool = shepherd.shear( shepherd.sheep[ n ] )) or to the lower 
>>ones (wool = shepherd.sheep[ n ].shear(), or rather 
>>wool = shepherd.sheep[ n ].get_shorn())? Does the shaving 
>>method logically belong to the sheep  (get_shorn) or to the 
>>shepherd (shear)?
> 
> 
> This is indeed one of the bigger problems I've seen in large OO
> projects: where design rules have not been sufficiently detailed,
> different teams tend to implement methods at different levels 
> in the class hierarchy, and it eventually becomes very difficult to
> reuse code or adapt to new features.
> 
> /Uffe
> 
>