| |
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.
References
- The Home
Page
The
Home Page part 2 Java
Criticism Shapes
Example The current article is the
third review of the above links and that site.
- Don't
Grow Trees?!
This link was the
second review, accepting and elaborating the Tree bashing of
that site.
|