What is OOP?

An exploration: From the first principle

S V Ramu (2002-03-30)


This article too is a sort of shadow boxing with that OOP Oversold site. I must make it clear that I have no direct relation to that author or the site; in fact I'm too new a comer to this Internet game or OO for that matter. I happened to stumble upon that site as a casual net browser and searcher, and I'm highly provoked by that site's content. Both positively and negatively. As much as he likes to play the devil's (procedural) advocate, I too would like to play that to OOP, assuming that Procedures are saints.

It is interesting because, the author does say many of my own pet grudges against OO. For all I know he(?) might be some grand old man, since his cynicism is bit too caustic, and his points are bit too eloquent and lot of escape clauses and proactive expectations. He must be having strong programming experience, if not in OO itself. If in reality he is not mentally too disturbed with OOP, as he sounds, then that site should be the best example of virtues of sarcasm. Whatever you can say, he does have a point to ponder. O boy! That author is really good in the rules of rhetoric. So, no programmer should fall prey to his provocations to give a proof for OOP, believe me that it is not easy, especially in his terms. Paradigms take an era to be proved. It also seems, that some of his articles (maybe the recent ones, especially the ones on trees, typing etc) are very deep with OO understanding and lot of tolerance and appreciation towards it.

By the way, maybe this preoccupation with that site should end anytime soon. As my intention is to arrive at strong pointers for simplistic and fool proof programming, this one pointed digressive endeavor to explore more of the OO's heart, in the name of that site is only natural. OO to me is like any other problem, very dear now, but nothing close to being my life or death. All said, to me too, who is writing this article, it is not very clear, what exactly OOP is. There are few areas that are very beautiful when I work with Java, and I try to ponder whether that can be called as OOP.

Is OO a Fad?

OOP is a lot like those idealistic development fads that failed to prove themselves in the real world. Expert systems, CASE, and 3-tier client/server technology are three other examples of technology that failed in the real world or took on a niche status. After the market place realizes the shortcomings of these technologies, the die-hard supporters always say the same thing: "They WOULD work if people simply used them properly." We are already hearing this from OOP apologists.

This is a powerful statement. This 'game' is really a powerful indicator of some internal failing. All the same, in the argued context, I don't feel that commercializing a concept is anything new, and need not be harmful, if the consumer knows what his wants really are. Yes, in this pitting of minds, the poor developer is misled. But I'm not sure whether we can ever stop this type of hype. If that site is an reaction to his understanding of what is hype and what is not, then it is good for him. I feel many a developer, have only acted from their strengths. Even if the whole world holler something, an individual can and will use only what he knows well. Of course the guilt will be there, if he is not sure. And sites like that is a great help in that direction. Even so, this could be done with lot less malice and adrenalin rush.

Maybe CASE is a failure, even so, its intention of automating and measuring software development is not a treason. Like what Edison said, a failed experiment is knowledge too. Yes, many companies did make some quick money; but can that be ever stopped? OOP is not a fad at all, and not a 'holy grail' too, as that site points out.

Is OO the Method Overloading etc.?

As that site rightly understands, OO is not directly related to many of the concepts that come with a proclaimed OO language.

OOP also benefits from miscellaneous programming language enhancements implemented in object-oriented languages. C++ benefits from important miscellaneous enhancements not really related to OOP: strong typing; function overloading; placing declarations anywhere; C++-style comments; reference arguments to procedures and reference return values; const declarations; simpler, cleaner storage management using new and delete operators; and inline specifications. These enhancements make C++ a better language than C independent of the OOP enhancements, but the benefits of these enhancements are often not distinguished from the benefits of OOP.

(Subject-Oriented Programming - James M. Coggins)

Having said this, giving an argument for each of the wrong claims is only academic. Read the above list carefully, I often come across people saying one of this is OO, and thereby accepting that they neither know OO nor that programming aid fully. But it is not their problem alone. OO is not well defined for many. Though some aspects are clearly NOT OO per se, there are others, which are very controversially placed. Of course you must also consider that may be few of these non-OO ideas might in fact been inspired by OO's spirit. What is that spirit? That is what this article is trying to explore.

Is OO the Real World Modeling?

Again as that site unravels, I have always been uncomfortable when trying to do that. I still have a bad taste when considering suggestions like Noun Phrase Analysis of the requirements text, as a way to arrive at initial list of Objects. This is too ideal and inhuman to be possible. OO is definitely not such a craft; it is still largely an art, if not plain Faith Healing.

If you see a Design Pattern, most of those participating classes are not even remotely related to reality. What reality does Strategy pattern picturize? I think the intention of the statement must have been, that OO is imagining in some granular units, which aids resolving the problem, for extensibility, in mind's reality. Yeah, contrived, but I cannot see much reality in OO modeling. Of course, data structures like Chairs or Employees are traditionally given as examples. But in reality ;) even my edit boxes and other seemingly simple components are split into various constituent classes for extensibility sake. There is no reality there, other than reality of convenience. I can understand why that site is so frustrated with such blown up claims. With all my tolerant preaching I cannot but show my anger towards such misleading claims. Anyway, taking my own pill, as long as we know what we want, wrong marketing shouldn't matter, except to trigger us to stand up and call the bluff with equanimity. For this alone, I would like to give my unconditional praise to that site.

Is OO the Inheritance?

This is a very old weak point of OOP. I think it has been time and again concluded that inheritance is inherently dangerous, except as an elegant way to copy code (i.e. reuse). The fact that none of the 23 famous design patterns put excessive stress on deep (more than one or two levels) inheritance, is a good enough proof that, Inheritance is just one another pattern, and not the OO spirit itself (though it was touted as such in C++ days). I fully agree with the authors views that trees are dangerous and limiting (please see my previous article on this angle). Only way in which I would like to differ would be: That author use that as a blemish of OOP, but I would like to treat it as a blemish in general programmatic thinking itself. I don't find any kick is putting all our energies in bashing something, as much as he doesn't like putting all our energies in praising something beyond truth, blindly and 'addictively'.

Is OO the namespace?

This is a tough question. If given no opposition I tend to accept that OO Encapsulation is much better than simple namespaces. But giving much more thought, like imagining that methods and variables of C being grouped under public-private style of identifier labels, I don't see whether namespaces are OO only concepts.

Thinking in these lines, it also seems that, OOP is the good qualities of many paradigms rolled into one, with some enhancements of its own. Of course taken in that sense there is no contradiction. But this is diluting the word, way too much. Though grouping of variables and methods can be done in a properly scoped C like procedural languages, the OOP Encapsulation does have something more in it.

Is OOP, creating new data types?

Yes. Now I think, we have hit the fringes. I have heard for and against the C struct being OO and non-OO. For one thing, struct have been with C long before C++ . Still, it does have the key quality of OO, namely Instantiability . Even robust namespaces can only group things together, but cannot lend to creating a new instance of it. Whether this instantiability is useful are not is a different question, but whenever we talk about OOP, this factor has to be considered to complete the picture.

After all OO didn't come out from vacuum, and it still even uses methods. So, struct is definitely a part of OO definition. That site too accepts this as the central idiom of OO thinking. In a way this is the nexus between procedural and OOish paradigms, where they meet.

OO is, focusing on nouns with all verbs bundled

This is clearly a OO speak. The stress on Nouns in contrast to verbs (as in procedural languages) is a very distinct OO stress. That site does provide a novel idea saying that OO is only the duel of procedures, where OO is noun based bundling, and procedures are verb based. This is a very appealing thought, and I think the real highlight of that site. There is lot more to this than is emphasized there, and worth further study.

For now, there are few differences that should be kept in mind (not unique to OO maybe, all the same important).

OO is, Polymorphism: Dynamic binding

This is a very powerful point for OO. This is a beautiful point too, needing an essay onto itself. The idea is that, action should change based on dynamic type checking and method dispatching. I'm frustrated with this being compared with method overloading, which is static binding, and has nothing to do with OO. Polymorphism can only be symbolized by Method Overriding. Together, Instantiability (or Encapsulation? Which naturally includes Noun focus), and Polymorphism, could be truly considered as two defining points of OOP.