The reason WHY OO sucks
Sun Jun 15 13:41:37 CEST 2003
At least I'm not the only one working on a Sunday, I don't feel so
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.
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
> 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.
More information about the erlang-questions