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
