art0031

When I first came across this site while searching the web for examples of OOP pitfalls, I was so sure that this was some sort of attention grabbing attempt. Well, after reading so many other pages from that site (beware it is hosted in geocities, and you can be locked out, if the page exceeds its quota of hits), I'm not so disturbed or antagonistic towards its intention, as previously I was. Its authors (Findy Services and B. Jacobs? as the copyright notice in the page footer claims), are pretty serious about its contents. It is no Joke Alone for sure, there is a useful message in it too. It is a very provocative writing. The authors (say, He) 'challenges' the reader to dare to give an useful example for OO's claimed superiority. He himself gives so many angles to the hyped status of OO, and Java (the symbolic straw man, so to say).

First I must frankly accept, that I've always been uncomfortable while trying to give an example for OO's usefulness. In the same vein, I've always also been very thrilled while trying to break a scenario into OO before coding. It is not the hype at all that made me like OO, because I started loving it only when I faced a wall with VB 4.0, and C++(when used as C). I hope you will take my words, when I say that 'I stated using OOP, only when I saw it working for me'. Of course, I say this only to imply that, as much as it is hard to give an example to OO's superiority, it is equally hard to give a truly deploring example of OO's subordination by Procedural languages. The author of the site, understandably rejects all one point OO solutions, as, too specific to conclude that OO is great enough. I feel, with the same token, all the counter-examples given in the site too are too specific to debase the whole OO movement as such.

For the past couple of years, while being very excited by the OO model of modularity, I always told my friends (and myself), that OO is only as good as your modular design is. And modular, extensible and reusable design, is no sole property of OOP alone, but common for any software designing in general. But after seeing the site, I'm more and more certain that OOP is not a technique or a product, whose performance can be measured upfront and once-for-all. OOP is, as the site claims, just a concept, a paradigm. And proving a paradigm might sometime take even decades: Maybe we can take relativity and evolution as examples?

God! How well the author rams in the point, that OOP is only a paradigm. However hard I prove that the site is asking for the impossible (as impossible as asking for the inferiority of OOP), I must accept that the site does do one great job: Opening our eyes to the fact that, OOP is only a paradigm, and it can only be as great as our design. I've always believed and preached this, but never with such vehemence or certainty. But, apart from the warning angle, and the load of valid sarcasm towards too much preponderance of OOP, I don't see that the site as a proof of the dominance of procedural (or TOP for that matter) over OOP. As much as the author thinks that he can challenge for a valid superiority proof of OOP, I can also ask for similar proof for OOP's inferiority (as complete as he wants it to be).

No, my intention is not to meekly counter him with another challenge, but to convey that, OOP is not a product or a technique to be easily proved or disproved of its 'usefulness'. And the author, by forcing me to say this, has succeeded, in putting across his point; that OOP is too oversold, to the detriment of other possible useful paradigms. Though I assume, that many first-hand OOP patrons, like me, would agree, that we always were aware of its dependency on our understanding, it is this site which rises this alarm one notch higher, and validly so. By first-hand understanding, I mean, praising OO not as a be-all and end-all of programming, but as a very useful model, or a mood, personally and in our mental privacy, due to our own problems and their solutions, and not just as a culturally cool thing (of course, that too).

Historically, why did procedural language win over assembly language? Of course, we can always program whatever we want in assembly, as much as we can with procedures. But procedures do give a higher level of grouping than assembly, and that is the reason. It is said, Human mind can remember only seven things randomly (definitely only a finite number, if not seven). After that, we rely on the grouping and classifying, to simplify our problem. Maybe, we reduce the number of unconnected groups to seven always! The point is, grouping is a natural way for humans to simplify and comprehend reality. I take that, OOP is only a natural extension of the procedural model, where we now group even the procedures (while the procedure grouped statements, and statements grouped assembly commands). In this light, I don't see any tension between OO and Procedures.

In fact, C++ is one such transition steps, before it was recognized that OO level of grouping is a must. You can consider QBasic, as a similar transition from Top-down programming to procedural. Like C was the landmark point at which procedures were established useful, Java is that popular landmark for establishing OOP as the basic building block. While working in QBasic, I do remember the days when I sort of crossovered to procedures as the way to go. In QB the methods are optional but in C++ it is the basic stuff from which we build every thing else. How can we say that grouping is inferior? It is only whether, we are ready for it as a community are not. When a concept is new, people are not forced to follow it, but when it is tested little bit, and the elite are comfortable with it, it is pushed down the throat of the commoner and starters too. Though this is cruel in a sense, the starters are at least surrounded by the new idea, which the elite had to do it all by themselves. This is a natural progression, nothing to be too excited or be putdown by. Maybe you can read my OOP=E+P article, that I wrote long time back. I like it, but it is only a groping attempt. Not complete at all, but in some sense an interesting summary.

In many sense the GoF (Gang of Four) book has been an eye opener to me. I have lot of reservations against DP being again the be-all of OOP thinking. If anything, it is a an important step towards the formulation of axioms of software programming. All the same, every concept should go through the patterns phase before formulating more exhaustive frameworks. Even the authors of DP do not proclaim it as OO-only concepts. Design Patterns, are the general programming patterns, like it is for civil architecture (where it became famous). If I may quote from the GoF DP book...

The choice of programming language is important because it influences one's point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance," "Encapsulation," and "Polymorphism." Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor (page 331). In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other. (See Iterator (257) for an example.)

In this sense, even procedures would be patterns, if we assume Assembly language as the base. Clearly, Design Patterns are only generally useful programming tricks, and not fully a part of any particular programming paradigm; be it OO or procedural. Yes, as the author of the site states, reusability and modularity are very very tough goals to achieve. And hence, a given OOP design not being up to a mark, cannot be taken against it, as it cannot be with a procedural model. Inheritance and classes can be used very badly, just like a method could be. If you haven't forgotten (or seen) the days when you transcended form plain Top-Down programming to procedures, you will accept the seemingly steep, learning curve of OOP. Maybe check out the LooslyCouple article, for the way I basically approach OO designing.

Recently I read an article from the ObjectMentor site, about the danger of wrongly assuming a class to be a subclass of an inappropriate super class (maybe I'll write about it soon). But I also learnt somewhere else that, you can never be completely certain as to whether a given class can inherit from another, unless you specify the context and compromises thereof. Similarly, you can never say that a given design is completely modular enough, unless you are given the reality requirements. Maybe that is why, producing a good example of OO's superiority (or for that matter Procedure's superiority) is tough. Yes, OO is definitely not everything, but not inferior to procedures. If you accept the grouping benefit of procedures over simple top-down (goto based) programming, then you cannot deny the merit of OO based bundling (using classes) over the procedures. OO is just an extension over procedures.

I love the author's cleverness in enumerating the possible abuses that he can get, and proactively (or is it reactively?) answering them in his herrings page. Of course, I'm not saying all that to him. On the contrary, I can only praise him for this sarcastic, but thought provoking and useful effort to put OOP in its place. All said, OOP is definitely an improvement, to my mind. In what sense? I'll try to explore in the coming weeks. My intention in writing this review is only give something to chew, for those lovable anti-OO campaigners out there. Look no further, this site calls OOP in all sorts of names, and abuses. I'm both thrilled by its relevance, and its limitations.

By the way, I haven't completely reviewed the TOP (Table Oriented Programming) model explained in that site. I also do not claim that I've read each line of that voluminous site. I intend to, and will share it. Stay tuned.

'OOP Oversold'?

A critical analysis of an anti-OO site

S V Ramu (2002-03-24)