What is OOP?

An exploration: From the first principle S V Ramu (2002-03-30)

Prelude

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).

Instantiation to verbs is tough to imagine, if not impossible. Without state, there is
not much point in instantiating things. But verb like nouns like Strategies, are only
a OO version of methods, and hence doesn't need instantiation, but once.

Any verb can be made as a noun, not vice versa(?). For example the strategy pattern is
clearly a polished function pointer (or delegates in C#).

Even in natural language we think in nouns (are we?). It seems that there are far more
nouns than verbs. Also, provided that there are enough different nouns, we can use the same
verb with the given noun to convey a different meaning (isn't this overriding?). Maybe this
point is a double-edged sword; needing more thought.

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.