Why is Object Oriented so successfull - Object

alexcpn wrote:

> Now a sudden thought stuck me. What if sometime in the future somebody
> armed with concrete statistics come and tell me that OO is too
> complicated and that most of the key words which we swear by like
> inheritance, polymorphisms etc really do not provide much value to the
> vast millions of OO code out there; I really believe part of this
> since I know a little about the code in one of the largest OO code
> base in the telecom network management product that I work in.

OO is not a methodology, so it can't suck. It's a tool. Hammers suck if you
need a screwdriver. A methodology sucks if it tells you to always use a
hammer.

If you define OO as "polymorphic methods behind encapsulating interfaces",
then saying "OO sucks" is the same as saying "polymorphism sucks", which is
trivially false.

Someday a better tool will arrive. OO won't suddenly start sucking. Hammers
were invented 1.5 million years ago, yet we still use them.

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath

On 11 Jan, 12:07, alexcpn <alex...@gmail.com> wrote:
> Recently I attended a seminar on Agile process which actually exposed
> the huge inefficiencies we where following in the waterfall method.It
> was a sudden awakening into something that you had an inking off long
> back.
>
> I have been developing software using OO A& D in C++ for over 5
> years , and have increasingly used more and more elegant/complicated
> designs; this is because I like programming and I also believed I was
> adding value. Have I modified source - yes a lot. Was the product
> successful - yes I guess.
>
> Now a sudden thought stuck me. What if sometime in the future somebody
> armed with concrete statistics come and tell me that OO is  too
> complicated and that most of the key words which we swear by like
> inheritance, polymorphisms etc really do not provide much value to the
> vast millions of OO code out there; I really believe part of this
> since I know a little about the code in  one of the largest OO code
> base in the telecom network management  product that I work in.
>
> Maybe I should frame the question more clearly- what is it so special
> in OO that makes it so successfully industrially. I really don't
> 'believe' that it is because of the way OO entity help us in closely
> modeling real life etc
>
> Is it the Open Closed Principle
> Or is it because there are not many choices
>
> This post is very subjective and probably I guess because of my lack
> of knowledge in many ares; anyway I am posting this for what it is
> worth so that I hope to get some illuminating replies

personally I think you've answered your own question...OCP would be
central for me....thats not to say the OCP doesn't exist in other
paradigms....there's obviously also, hype, marketing, it's a natural
extension ot procural programming, other paradigms required too much
processing power and so were not viable at the time (though this may
now not be the case) etc....and probably loads of others...take your
pick

alexcpn <alexcpn@gmail.com> wrote:

> Recently I attended a seminar on Agile process which actually exposed
> the huge inefficiencies we where following in the waterfall method.It
> was a sudden awakening into something that you had an inking off long
> back.
>
> I have been developing software using OO A& D in C++ for over 5
> years , and have increasingly used more and more elegant/complicated
> designs; this is because I like programming and I also believed I was
> adding value. Have I modified source - yes a lot. Was the product
> successful - yes I guess.
>
> Now a sudden thought stuck me. What if sometime in the future somebody
> armed with concrete statistics come and tell me that OO is too
> complicated and that most of the key words which we swear by like
> inheritance, polymorphisms etc really do not provide much value to the
> vast millions of OO code out there; I really believe part of this
> since I know a little about the code in one of the largest OO code
> base in the telecom network management product that I work in.
>
> Maybe I should frame the question more clearly- what is it so special
> in OO that makes it so successfully industrially. I really don't
> 'believe' that it is because of the way OO entity help us in closely
> modeling real life etc
>
> Is it the Open Closed Principle
> Or is it because there are not many choices
>
> This post is very subjective and probably I guess because of my lack
> of knowledge in many ares; anyway I am posting this for what it is
> worth so that I hope to get some illuminating replies

What is so special about OO is that it allows us to move up a level of
abstraction. I recently was doing some maintenance on C++ code that
manipulated some const char*s. The code had all kinds of temp pointers
and was doing all kinds of low level work. Rather than beat myself up
looking for the bug, I replaced the code and used a string class. That
increase in abstraction reduced the complexity of the code in every
measurable way and fixed the bug.

Note, the above has nothing to do with polymorphism.

"Daniel T." <daniel_t@earthlink.net> writes:
>I replaced the code and used a string class.

If you were using a non object-oriented, but procedural and
possibly modular language, possibly with support for abstract
data types and possibly even with garbage collection for
strings (as in BASIC), you could have said this as well:

»I replaced the code and used the/a string library/module.«

If it had garbage collection for strings, this feature might
even avoid more trouble than the string class in C++.

So, what was /specifically/ object-oriented about your
approach, that could not be done in a non object-oriented, but
procedural and possibly modular language?

On Fri, 11 Jan 2008 11:49:28 -0500, Daniel T. wrote:

> What is so special about OO is that it allows us to move up a level of
> abstraction. I recently was doing some maintenance on C++ code that
> manipulated some const char*s. The code had all kinds of temp pointers
> and was doing all kinds of low level work. Rather than beat myself up
> looking for the bug, I replaced the code and used a string class. That
> increase in abstraction reduced the complexity of the code in every
> measurable way and fixed the bug.
>
> Note, the above has nothing to do with polymorphism.

Yep, this is just ADT.

The question wether programming with ADTs or programming with sets of ADTs
(polymorphism falls here) is essential to OOP is open. However moving up
abstraction levels obviously requires the latter.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

alexcpn <alexcpn@gmail.com> writes:
>question more clearly- what is it so special
>in OO that makes it so successfully industrially.

Verbs can be extended without the need to modify existing code.
For example, in Java, a new type can extend the verb »toString«.
This extension can then be used immediatly by the existing
»println« verb, without the need that the author of the code
for »println« was aware of the new type, so it is not
necessary to modify the given Java SE library, which contains
other definitions of the verb »toString«. One only needs to
/add/ new code. Thus, the »open/closed principle« is fulfilled.

A Java program illustrating the answer to the previous question:

class Position
{ int x, y; public java.lang.String toString(){ return x + ", " + y; }}

public class Main
{ public static void main( final java.lang.String[] args )
{ java.lang.System.out.println( new Position() ); }}

0, 0

On 11 Jan 2008 16:59:59 GMT, Stefan Ram wrote:

> "Daniel T." <daniel_t@earthlink.net> writes:

> If it had garbage collection for strings, this feature might
> even avoid more trouble than the string class in C++.

Nope, that would be a lower level. Note that GC deals with pointers while
string ADT is a proper abstraction hiding implementation detail (char *).
The trouble was poor design, rather than just bugs.

Usually GC is used as a hack handle low-level abstractions which the
programmer did not care to re-think in a way that would clarify the
relationship between the objects. So he leaves that to the"magic" of GC
that should get things right. Sometimes it will, sometimes it will not.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

> On Fri, 11 Jan 2008 11:49:28 -0500, Daniel T. wrote:

>>What is so special about OO is that it allows us to move up a level of
>>abstraction. I recently was doing some maintenance on C++ code that
>>manipulated some const char*s. The code had all kinds of temp pointers
>>and was doing all kinds of low level work. Rather than beat myself up
>>looking for the bug, I replaced the code and used a string class. That
>>increase in abstraction reduced the complexity of the code in every
>>measurable way and fixed the bug.

>>Note, the above has nothing to do with polymorphism.

> Yep, this is just ADT.

> The question wether programming with ADTs or programming with sets of ADTs
> (polymorphism falls here) is essential to OOP is open. However moving up
> abstraction levels obviously requires the latter.

Type substitutability is what OOP (Simula) brought to the game (via
inheritance) . Type substitutability is a good means of implementing the
Open-Closed Principle, solving all the grief of the "variant record"
problem (coupling etc) .

Of course, just as ADT programming does not require OO prog langs, neither
does type substitutability (FP langs etc) . But the fact that OOP supports
both ADTs and type substitutability has been a key factor in its success.


Regards,
Steven Perryman

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>Usually GC is used as a hack handle low-level abstractions
>which the programmer did not care to re-think in a way that
>would clarify the relationship between the objects.

This »care to re-think« sometimes is too much of a burden.
Just as the »care to re-think« how to implement a higher-level
procedure in machine op-codes.

Two quotations regarding gargabe collection:

»Your essay made me remember an interesting phenomenon I
saw in one system I worked on. There were two versions of
it, one in Lisp and one in C++. The display subsystem of
the Lisp version was faster. There were various reasons,
but an important one was GC: the C++ code copied a lot of
buffers because they got passed around in fairly complex
ways, so it could be quite difficult to know when one
could be deallocated. To avoid that problem, the C++
programmers just copied. The Lisp was GCed, so the Lisp
programmers never had to worry about it; they just passed
the buffers around, which reduced both memory use and CPU
cycles spent copying.«

<XNOkd.7720$zx1.5584@newssvr13.news.prodigy.com>

»A lot of us thought in the 1990s that the big battle
would be between procedural and functional
programming, and we thought that functional
programming would provide a big boost in programmer
productivity. I thought that, too. Some people still think
that. It turns out we were wrong. Functional
programming is handy dandy, but it's not really the
productivity booster that was promised. The real
significant productivity advance we've had in programming
has been from languages which manage memory for you
automatically. It can be with reference counting or
garbage collection; it can be Java, Haskell, Visual Basic
(even 1.0), Smalltalk, or any of a number of scripting
languages. If your programming language allows you to grab
a chunk of memory without thinking about how it's going to
be released when you're done with it, you're using a
managed-memory language, and you are going to be much more
efficient than someone using a language in which you have
to explicitly manage memory. Whenever you hear someone
bragging about how productive their language is, they're
probably getting most of that productivity from the
automated memory management, even if they misattribute it.«

http://www.joelonsoftware.com/articles/APIWar.html