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!)

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

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.

In OOP, you spend your time trying to find Is-A relationships, but they don't exist. Unsurprisingly, hardly anyone is "really" doing OOP. It seems to be unimplementable.

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!)
> 
>> 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.
> 
> 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.
> 
> In OOP, you spend your time trying to find Is-A relationships, but they don't exist. Unsurprisingly, hardly anyone is "really" doing OOP. It seems to be unimplementable.

It might have been this way, but newer OOP books actually prefers has-a relationships before is-a.

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.

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

Sorry, Hasan this is called 'moving the goalposts'.

-DavidM

"Don Clugston" <dac@nospam.com.au> wrote in message news:dv3bm6$24ed$1@digitaldaemon.com...
> In OOP, you spend your time trying to find Is-A relationships, but they don't exist. Unsurprisingly, hardly anyone is "really" doing OOP. It seems to be unimplementable.

The dmd compiler front end seems to be a natural fit for OOP.

On Tue, 14 Mar 2006 03:18:30 +1100, Lars Ivar Igesund <larsivar@igesund.net> wrote:


>> In OOP, you spend your time trying to find Is-A relationships, but they
>> don't exist. Unsurprisingly, hardly anyone is "really" doing OOP. It
>> seems to be unimplementable.
>
> It might have been this way, but newer OOP books actually prefers has-a
> relationships before is-a.

That's interesting. I've been thinking of classes as having a set of behaviours and a set of properties for ages.

-- 
Derek Parnell
Melbourne, Australia