D - more power than (really) needed !

[Hasan Aljudy]

Don Clugston wrote:
> Hasan Aljudy wrote:
> 
>> David Medlock wrote:
>> <snip>
>>
>>> see:
>>> http://okmij.org/ftp/Computation/Subtyping/#Problem
>>>
>>> -DavidM
>>
>>
>> A nice example of not understanding OOP :)
>>
>> WOW .. I think I'm beginning to understand what Schock means when he 
>> says everyone out there thinks they are doing object oriented 
>> programming, but only very few of them really are.
>>
>> There's no "book" that you can follow literally to produce good code. 
>> It's a matter of trial and error. You try to subclass CSet from CBag, 
>> and disvocer that it doesn't work, or produce more problem than it 
>> solves, then don't whine about it, just implement CSet differently. 
>> It's not OOP's fault, nor is it inheritance's fault.
> 
> 
> I disagree, I think this is absolutely OOP's fault. 'Trial and error' 
> seems to be a fundamental feature of OOP. If you use OOP, you are 
> committing yourself to continually restructuring your code. (OOP is the 
> worst thing that ever happenned to code reuse!)

Are you saying you have a mechanical way to write perfect code?!


> 
>> If you try to open a door with a screw-driver and it doesn't work, 
>> should you blame the screw-driver, or blame yourself for not 
>> understanding how doors work?
>>
>> Apparently subclassing CSet from CBag wasn't such a good idea. Don't 
>> blame the object oriented paradigm for it. No where in the paradigm 
>> does it say that you should sublcass CSet from CBag!
> 
> 
> And this is the problem. It gives no guidance for when you should use 
> subclassing. That turns out to be a fantastically difficult problem, and 
> OOP just glossed over it.

OOP's main guide is cohesion, whenever you have a class that's doing too 
much, you should redesign your code and split your class into multiple 
classes.
When you see more than once class using pretty much the same code, you 
should think about pulling this common code to a super class. etc.


> 
> Fundamentally, I think the fatal flaw in OOP is that "is-a" 
> relationships do not exist. (Well, _maybe_ for abstract geometrical 
> shapes, but definitely not for anything useful). The text book examples 
> are wrong: a 'Manager' is NOT a type of 'Employee'. An 'Employee' is NOT 
> a type of 'Person'. Actually, 'Object' works as a base class, because 
> every object really IS-A block of bytes in RAM, some of which are 
> organised into a virtual function table. But note that it's not some 
> kind of abstract Platonic entity. It's a bunch of transistors.

A Manager doesn't always have to be an Employee, it depends on what 
your're doing. However, most of the time, if you find yourself writing 
the same code in the Employee and Manager classes, then you should 
probably think about pulling some code up the class hierarchy. You can 
create an AbstractEmployee, for example, and put all the duplicate code 
in there, then let Employee and Manager inherit from there. That's just 
one possibility, it may be a good choice in some situations, but it 
could be a very bad idea in some other situations. It all depends on 
what you're doing.

> 
> In OOP, you spend your time trying to find Is-A relationships, but they 
> don't exist. 

dude, you're trying to come up with classes and/or class hierarchies 
before examining the problem at hand!! You can't do that!!
If at anytime, your design goal becomes to "find a use" for inheritance, 
i.e. find is-a relationships, then you're going the wrong path.

in OOP, you analyze for /objects/ .. object, not classes.


> Unsurprisingly, hardly anyone is "really" doing OOP. It 
> seems to be unimplementable.

No, they just don't understand it.