On Sun, 31 Jan 2016 09:42:28 -0700
"Keith Medcalf" <kmedcalf at dessus.com> wrote:

> 
> And I thought the "Object Oriented" jihad blew up when it was discovered to 
> be counter to productivity and performance in the 1990's and that it did not 
> provide a single one of the "advantages" claimed by its mujahedeen warriors.
> 
> Of course, it could be that there is not really very much of anything at all 
> (if there is anything at all) that implements an "object oriented" 
> architecture.  It is mostly just glossing appearances and wrappers around 
> inherently non-object oriented things.  But then again, that just goes to 
> show that OO is inherently flawed.
> 
> OO is a dead horse.  It is about time it was finally shot in the head and put 
> out of its misery.

I'm off?topic, but this is going a bit too far in the opposite direction.

I won't be so much affirmative about OO being entirely negative; there are 
cases where it matches well. These cases (as I experienced them) are when there 
are 1) not that much objects (I mean 100, as an example, not 10 000 or 1000 
000) 2) there each have a strong personality, that is, there differs enough 
from each other instance, while have enough in commons (both). This is 
typically the case with user interfaces (although state?machine are nice too in 
this area), as the human being is a complex thing :-D with many peculiarities, 
which are well matched by OO with it's deep inheritance and attributes 
everywhere (prototype based OO is nice too for this purpose).

A fact is that a user interface as in this example, works at a tempo which is 
the same as that of a human: quarter of second or something around; it normally 
consumes not that much resources (objects are not responsible for heavy 
graphics). It does not do computation, it behaves. That's the word I believe: 
OO is good at expressing peculiar behaviours, more than at expressing 
computation (if one does not confuse records and OO's objects).

The overall criticism I would still have against OO, is that in its typical 
implementations, it confuses interface inheritance and implementation 
inheritance, which in my opinion, should be separate (some OO languages have 
private inheritance at least, ? unfortunately, most famous languages don't). An 
other issue (however cleaner solved by Eiffel, unlike others did), is name 
conflicts in inheritance. The implementations and the model, are still two 
different things.


-- 
Yannick Duch?ne

Reply via email to