Sep 18, 2004

The Rise and Continued Rise of Object Orientation...

Over at Informit, Danny Kalev has an article entitled “The Rise & Fall of Object Orientation.” I find that this the article is trying to suggest something, but does not provide any real substance to support the idea.

For example, in the examples that he presented for the inheritance flaws, in all of these cases it seems that the rule to only use inheritance as a Is-A relationship was not held, and the real reasons for inheritance was code reuse. The realization of reuse comes from more than simply inheritance; it comes from the fact that a class should be written to do a single function, and therefore, this representation can be reused for multiple projects. This is not limited to an object-oriented paradigm, but this can be easier to do in object-oriented languages. As mentioned in Leveraging Frameworks, writing frameworks is not easy, and many framework projects fail; as such, using examples that are frameworks is probably not the best example. What about other object-oriented projects, such as ACE, for example. This project has been around for a while, and to my knowledge, has not had a huge rearchitecture, rewrite, or was renamed, such as the examples that he provided.

C++ has historically been known for having shallow class hierarchies, whereas other object oriented languages such as SmallTalk and Java generally have deep class hierarchies. The lack of derivation should not been seen as bad, but merely a different approach that C++ culture prefers. The argument of inheritance propagating bugs is also lame, as your classes should have some genre of test cases, and per se that there is a bug in a class that has five classes that derive from it, in this case, you have just fixed bugs for all of them. When a class hierarchy, containment, or generic algorithms are not preferred, this will usually result in classes maturing at different rates, as bugs will usually only be resolved in portions of the code instead of the entire code base.

The example of avoiding member functions is also weak, as a library of containers should probably be deriving the from a base class of some sort for the size() function, with the possibility of being specialized. While it is true that you could implement this via the std::distance algorithm, this could be optimized by having a member function. As a complete counter to the argument, think about Item 44 of Effective STL, which prescribes that you should prefer member functions to non-member functions. If member functions were included in each container, then it would be easier to implement code using an std::list and then change it to a std::vector with minimal changes.

This article appears to be suggesting that everything should be generic, but interestingly enough, Danny also wrote an article on over-engineering, in which talks about being over generic. This appears to be a mixed message. Personally, I think it generic programming and object-oriented development are techniques that developers should know how to use, and when developing code, choose the technique that is the best for the situation.

Filed In