Re: Advantages of object-oriented programming

Responding to Ram...

I was trying to write about the "advantages of
object-oriented programming".

Some other texts about this topic write sentences like

- methods are kept with related data as one object

- inheritance helps to reuse code

But I did not wish to follow these lines, because I do not
consider classes or inheritance to be a neccessary part of the
definition of OOP.

I agree that those characterizations don't have a lot to do with what OOA/D/P is about. However, they are a lot closer than saying that neither classes nor inheritance are part of the definition of the OO paradigm.

Class systems are absolutely crucial to OOA/D because they provide the level of abstraction for logical indivisibility, provide a basis for problem space abstraction, and enable relationships whose participation is the primary mechanism for limiting access to state variables in the OO paradigm.

While inheritance is less important than class systems to the OO paradigm, one still needs a suite of rules for resolving properties of individual objects in a generalization/specialization relation. Since inclusion polymorphism is one of the more important OO tools and it is enabled by generalization, one can't really dismiss inheritance.


To me, this is the dispatch on the run-time type (run-time
polymorphism).

For the invocation

f( x )

, the method actually called depends on the run-time type of "x", while in a language that is not object-oriented it does not.

I'm afraid I don't follow this. In C, FORTRAN, or whatever the type of 'x' must be consistent with the signature defined for 'f'. In this respect the OOPLs use exactly the same conventions as procedural languages; they just support a broader range of types.

OOPLs, though, do allow overload polymorphism by allowing different signatures for the same method. That, however, is probably the least important form of polymorphism that the OO paradigm provides. (It is not even relevant to OOA/D because one deals with knowledge attributes at a much higher level of abstraction.)


Does this dispatch has advantages?

In a object-oriented language, I write method definitions
for each type (ignoring sub-types for simplicity):

f( A x ) := 1. /* case 0 */
f( B x ) := 2. /* case 0 */

In a language that is not object-oriented, I'd write:

f( x ) := run-time-type( x )== A ? 1 : 2. /* case 1 */

So, why should the first notation be better than the second one?

Your OO example is overload polymorphism. Generally that form of polymorphism is not available in most non-OO languages. One can emulate it in a variant on ad hoc polymorphism in some scripting and other specialized languages as you indicate. But in most languages one cannot test the type of an argument.

The closest thing one normally has in general purpose languages is ad hoc polymorphism where one tests the /value/ of the argument to dispatch to a behavior. Ad hoc polymorphism is done exactly the same way in the OO paradigm.

However, I think this is academic because...

Is this the most important advantage of run-time polymorphism
/ object-oriented programming?

Overload and ad hoc polymorphism are of relatively minor importance in the OO paradigm compared to inclusion and parametric polymorphism. (Parametric polymorphism is the more general sense of modifying behavior through parametric attribute data rather than the uniquely 3GL view of type substitution via mechanisms like STL.)

Parametric polymorphism, through the use of specification objects, is especially important to OOA development because it enables encoding invariants while relegating detailed differences to attribute values. That can drastically reduce overall code size and, consequently, improve reliability.

Inclusion polymorphism is especially important to OOP development because it is the primary tool for addressing the physical coupling problems inherent in 3GLs through dependency management.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... >>>dynamically checked OO languages, but iirc that isn't the case. ... >> I have written enough code in Smalltalk, ... to know that polymorphism and inheritance are not ...
    (comp.object)
  • Inheritance and Polymorhpism (getting back to the point)
    ... >replaced with an inheritance hierarchy. ... languages that, for the purpose of this discussion, we shall call ... "common statically typed languages") polymorphism is achieved through ... is also stipulates that there may be some dynamically typed languages ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... >>> I have written enough code in Smalltalk, ... >>> associated in those languages. ... "polymorphism and inheritance are not associated in those languages" ...
    (comp.object)
  • Re: To understand OOP better...
    ... > could support dynamic polymorphism through the use of evil weakly-typed ... Polymorphism via inheritance is known as inclusion polymorphism. ... the way object responsibilities are defined (i.e., ... > BTW, encapsulation is deprecated. ...
    (comp.object)
  • Re: Basic Explaination of OO in Ada
    ... Programming by extension does not necessarily involve inheritance. ... package Pak2 is ... access types are not necessary to achieve polymorphism; ...
    (comp.lang.ada)