This post originated from an RSS feed registered with Java Buzz
by Carlos Perez.
Original Post: Is It High Time To Get Rid Of Classes?
Feed Title: .:Manageability:.
Feed URL: http://www.manageability.org/blog/stuff/rssDisabled?portal_status_message=Syndication+is+Disabled
Feed Description: Random thoughts on the manageability of complex software.
James Coplien, the guy who got everyone talking about Idioms in C++, has now started blogging. He's got this extremely long piece on how to teach object orientation and he's got a pretty radical conclusion. He's saying its high time to get rid of classes!
No, he doesn't want to make his own teaching job obsolete. What he's talking about is about the concept of classes in Object Oriented Design (OOD). He writes about OOD from the perspective of teaching a course, however just like everything he's previously written, there's so much hidden gems that needs serious parsing to excavate.
He speaks about some conceptual difficulties with class based modeling:
But when we combine a hierarchy of related classes under a common construct that groups them together, we too often just use the concept of "class" again. The problem is that it's not a class any more: it's not a single structure that captures the structure of all the objects of all the classes being grouped together. Making this level of abstraction into a class discards the information that the resulting entity stands in for a larger number of classes in the subtending inheritance graph.
He talks about interfaces and why they are more about objects than classes:
The first is that roles are more about objects than they are about classes. A class is a total classification of objects. Rather than thinking of a role as a partical interface to some class, it might be better to think of it as a partial classification of a set of objects.
the fallacy of modeling the world using a single perspective:
Second, because they are not total classifications roles break down the tyrrany of hierarchy. That is a better match for the real world. When God created the world, she did not create it as a hierarchy of classes. She may not even have created it, as Kant might insist, from a universe of discrete, identifiable objects. Roles provide the freedom to define a software reality that can align with a myriad of important design perspectives that range from the marketing view to the structural view.
and the synergy between roles and use cases:
Third, because roles are closer to objects, they are closer to the structure of Use Cases than classes are. Objects are run-time animals, and the role interface to an object reflects a set of responsibilities related more by some function than by any structural consideration. Yet as partial classifications, roles can also bridge the gap to the structural world. This is perhaps the most powerful contribution of roles: as a locus for the intersection of structure and function.
Many readers however might think that he's just babbling along, however I've dug up some hard evidence that should lead to the death penalty for classes:
Exhibit A. Component Models.Component models aren't class based, they are object based. When you bring up a java bean in a palette and customize its properties you are essentially modifying an object instance. The way to add new functionality is to attach an event handler to the instance.
Exhibit B. Multiple Viewpoints. An illustrative explanation of this can be found in the OpenCyc documentation "Why use logic?". In fact, anybody who has worked with OODBMS will realize the difficulty in fixed hierarchies.
Exhibit C. Conceptual Impedance Mismatch. It's never clear what delineates a class and an object. All to often its conceptually more precise to represent a class as an object. In fact, Ralph Johnson's Adaptive Object Model architecural style points to modeling of objects in terms of objects.
Exhibit D. Dynamic models. Dynamic models are instance based, for example dynamic inheritance is implemented via delegation which is instance based. James Gosling, if only he could find a good solution, would have thrown out class inheritance all together. Also, AOP should be done at the object level and not at the class level as many are proposing. "Fluid AOP" takes the right approach of binding aspects at the instance level and not at the class level.
So, James Coplien appears to be on the right track when he says "This perspective combines a small number of fundamental concepts into a consistent, integrated picture of the fundamentals of object orientation".
Finally, one last question I've got to ask, if roles (i.e. Interfaces) are so important, then why aren't they also objects? Curiously, the only project I've heard to about interfaces as objects is PyProtocols.
Previous Topic
