Most people praise Object-Oriented techniques as the greatest blessing since the introduction of "structured programming" by E. Dijkstra. The question is whether this is the case.
Object-Oriented (OO) has been the buzz-word for almost a decade now. You have all kinds of OO things now, ranging from OO programming languages, to OO development methods, and from OO diagramming techniques to OO database systems. But the adjective OO does not say much. There is a world of difference between the two OO programming languages C++ and Smalltalk. There are at least five OO dimensions to each OO programming/system. These are:
Objectiveness. The extend to which things are objects. In Smalltalk everything is an object and all functions are methods of an object. In C++ you have ordinary functions and integer values.
The class construction model. Does the language have inheritance, multiple inheritance, interfaces, polymorphism, and so on. Visual Basic is called an OO language and it does not even have real inheritance. Java does not support multiple inheritance.
Are classes defined statically or dynamic? Are classes first class objects?
The object construction model. How are objects instantiated? How are they destroyed? Do you have to do it yourself, or is it done automatically? Does the runtime environment do garbage collections?
The type system. Is there strict typing? Is it possible to invoke a method without knowing the exact class of the method? Is there reflection?
The object life cycle model. How about object persistency? Can object being transfered between computing entities? What about external references to object?
This makes that there is almost no general idea, let alone a consistent theory, about what an Object-Oriented language/system is. In practice, large systems often make use of OO languages and databases which operate with completely different and sometimes even incompatible object models. (Read a comparison of some OO programming languages for some more details.)
One of the problem with Object-Orientation is that virtually everything can be considered as an object. For example, one could consider procedures as objects which are created when invoked, and destroyed on exit. Objects with just a single method, but that does not matter. That this is not even such a strange idea, proofs that it can be used to implement platform independend cooperative multi-threading in C. (See footnote 1 about C not being OO.)
One of the reasons why OO progamming languages were introduced, was because it would help implement non-trivial systems. Classes gave you the ability to encapsulate implementation details. This argument is of no use for OO specifications, because in a specification there is no need for encapsulating implementation details, as a good specification should abstract from all implementation details. Although through the years many OO-libraries were written, OO did not really make code-reuse a reality. The Standard Type Library (STL) is a good example of a more succesful general purpose OO-library, but it is only suitable within the C++ execution model, and of no use when trying to communicate with an OO-database system over a network with a C++ program.
Another reason why OO was thought to be good, is because it would bring together the storage of some data, and all the operations on that data. At first this may seem to be a good idea. But lets take the example where we have a graph represented by objects, where there are objects for the vertices and the edges of the graph. And suppose we want to execute some graph algorithm which needs to store some additional information with each vertex in order to execute the algorithm efficiently. This would mean that the object model has to be modified in order to store some additional data which would only be used during the execution of the algorithm. The alternative would be to store the data in some look-up table, which maps each vertex object to another object containing the additional data that the algorithm needs. Often there are operations on an object model, which require to traverse the objects and execute a certain method on each object. If all the traversals are implemented as methods of the objects, it means that the traversal algorithm is spread out over the objects. There are certain design patterns which deal with these kinds of problems.
Object-orientation suggest that each object is responsible for itself. However, objects often have many references to other objects around them, and these references need to be kept consistent. Sometimes this results in some serious management problems when it is not clear which objects can or may manipulate the state of another object. Also the creation and destruction of objects always falls under the responsibility of other objects. It is especially hard to define consistent semantics in manipulating complex object structures.
The general conclusion of the above may be that although object-orientation seems to be very intuitive mode of thinking (once you have become acquinted with it) there are great troubles with defining the semantics of object models. During my involvement with the TransCoop project, I closely followed the formalisation of one object model, and came to the conclusion that it failed to do define clear and consistent semantics of the object model. Without a consistent data model, it is also not possible define a consistent specification language, let alone implement seaminglessly working object oriented systems.
- Objectiveness. The extend to which things are objects. In Smalltalk everything is an object and all functions are methods of an object. In C++ you have ordinary functions and integer values.
- The class construction model. Does the language have inheritance, multiple inheritance, interfaces, polymorphism, and so on. Visual Basic is called an OO language and it does not even have real inheritance. Java does not support multiple inheritance.
Are classes defined statically or dynamic? Are classes first class objects?- The object construction model. How are objects instantiated? How are they destroyed? Do you have to do it yourself, or is it done automatically? Does the runtime environment do garbage collections?
- The type system. Is there strict typing? Is it possible to invoke a method without knowing the exact class of the method? Is there reflection?
- The object life cycle model. How about object persistency? Can object being transfered between computing entities? What about external references to object?
This makes that there is almost no general idea, let alone a consistent theory, about what an Object-Oriented language/system is. In practice, large systems often make use of OO languages and databases which operate with completely different and sometimes even incompatible object models. (Read a comparison of some OO programming languages for some more details.) One of the problem with Object-Orientation is that virtually everything can be considered as an object. For example, one could consider procedures as objects which are created when invoked, and destroyed on exit. Objects with just a single method, but that does not matter. That this is not even such a strange idea, proofs that it can be used to implement platform independend cooperative multi-threading in C. (See footnote 1 about C not being OO.) One of the reasons why OO progamming languages were introduced, was because it would help implement non-trivial systems. Classes gave you the ability to encapsulate implementation details. This argument is of no use for OO specifications, because in a specification there is no need for encapsulating implementation details, as a good specification should abstract from all implementation details. Although through the years many OO-libraries were written, OO did not really make code-reuse a reality. The Standard Type Library (STL) is a good example of a more succesful general purpose OO-library, but it is only suitable within the C++ execution model, and of no use when trying to communicate with an OO-database system over a network with a C++ program. Another reason why OO was thought to be good, is because it would bring together the storage of some data, and all the operations on that data. At first this may seem to be a good idea. But lets take the example where we have a graph represented by objects, where there are objects for the vertices and the edges of the graph. And suppose we want to execute some graph algorithm which needs to store some additional information with each vertex in order to execute the algorithm efficiently. This would mean that the object model has to be modified in order to store some additional data which would only be used during the execution of the algorithm. The alternative would be to store the data in some look-up table, which maps each vertex object to another object containing the additional data that the algorithm needs. Often there are operations on an object model, which require to traverse the objects and execute a certain method on each object. If all the traversals are implemented as methods of the objects, it means that the traversal algorithm is spread out over the objects. There are certain design patterns which deal with these kinds of problems. Object-orientation suggest that each object is responsible for itself. However, objects often have many references to other objects around them, and these references need to be kept consistent. Sometimes this results in some serious management problems when it is not clear which objects can or may manipulate the state of another object. Also the creation and destruction of objects always falls under the responsibility of other objects. It is especially hard to define consistent semantics in manipulating complex object structures. The general conclusion of the above may be that although object-orientation seems to be very intuitive mode of thinking (once you have become acquinted with it) there are great troubles with defining the semantics of object models. During my involvement with the TransCoop project, I closely followed the formalisation of one object model, and came to the conclusion that it failed to do define clear and consistent semantics of the object model. Without a consistent data model, it is also not possible define a consistent specification language, let alone implement seaminglessly working object oriented systems.Recent Posts
Archive Posts
Tags