Subject/Object Confusion Syndrome [was: Ada Objects Help]

[jgv@swl.msd.ray.com (John Volan)]

hathawa2@marshall.edu (Mark S. Hathaway) writes:

>There has been some discussion recently on comp.object about the question
>of what mechanism should be used to bring together two (2) or more objects
>to work with and to affect.  I've suggested that in such cases it's always
>better to have such a "higher authority" than to allocate to an object a
>method which doesn't belong.  To have a mow() method in a lawn object seems
>absurd to me.  Since when does a lawn do anything but grow_crab_grass()?

Mark, you've fallen right into one of the prime conceptual traps of
the object-oriented paradigm: You've swallowed the fallacy that
"object-oriented software models the real world."  Despite the
all-too-frequent hype you might have heard, object-oriented software
does *not* model real-world behavior.  Object-oriented software --
like *any* computer software -- is a formalized model of the behavior
we want to elicit out of a *computer*.  Now, there might be a very
compelling *analogy* between objects-in-the-real-world and
objects-in-the-computer, but it's still nothing more than an
*analogy*.  Every analogy eventually breaks down if you push it too
far.  I would submit that the point where the "real-world" analogy
breaks down is precisely when you start trying to deal with behavior.

Definition: A software object is an encapsulation of a *computer's*
responsibilities *with respect to* some real-world object in its
problem domain.  

A software object encapsulates the computer's responsibilities to know
things (data) and to do things (processing) *pertaining to* some
real-world object.  This knowledge and behavior might bear very little
resemblance to the actual knowledge and behavior that the real-world
object itself might be endowed with.  In general, the purpose of
computer software is *not* to mimic what real-world entities do.  In
fact, the whole point is usually to hold the kind of data and to
perform the kind of processing that real-world entities are *not*
already capable of doing. Otherwise why bother programming?

>The authority which mow()s is not the lawn.  

Of course lawns don't mow themselves -- in the real world.  Of course
there's always some "higher authority" or "agent" actually responsible
for mowing a given lawn -- in the real world.  But if we're talking
about the real world, isn't our lawn-mowing *software* a *part* of
the "real world"?  Isn't the program itself that "higher authority" or
"agent" you're seeking?

Of course, our hypothetical program is probably responsible for mowing
a lot of lawns, and for mowing a lot of different *kinds* of lawns,
and for doing a lot of other things to/for/with/about/upon lawns, and
for doing things to/for/with/about/upon a lot of other things besides
lawns.  That's a lot of different responsibilities -- things are
getting pretty complex.  So it would be beneficial if we could to
encapsulate all those responsibilities in a nice compartmentalized
way.

Let's say we take all the responsibilities that pertain just to one
particular lawn of one particular type, and concentrate those
responsibilities into one cohesive software entity, distinct from
everything else in the system.  For simplicity, we might call this
entity a "lawn" object -- but never in our wildest dreams do we
imagine that it's *really* a lawn.  (Last time I looked inside my
workstation, I didn't see any sod on the motherboard. :-) No, a "lawn"
object is really just a particular chunk of our computing resources
that happens to be devoted to managing a lawn.  The only reason we
don't call it a "lawn manager" or a "lawn controller" is that the role
of "managing" or "controlling" is something you can assume about
*every* software object.  That's what software does: it "manages" or
"controls" or at least "keeps track of" things.  So it would be kind
of redundant to tack on that extra verbiage.  It should just be
understood.

Well ... this assumes that programmers actually *understand* what
programming is all about ...

>Create another object which
>can manipulate the mower and lawn objects.  How about...
>
>  class lawn_mowin_fool is
>    -- states:  poverty, drunk, out of control  :-)
>    proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower ) is
>      ...
>    end mow;
>  end lawn_mowin_fool;
>
>  spirit lawn_mowin_fool is
>    proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower );
>  end lawn_mowin_fool;
>
>  proc lawn_care () is
>    obj lmf is lawn_mowin_fool;
>  begin
>    lmf.mow(MyLawn,SearsSpecial);
>  end lawn_care;
>
>This way you can command lmf to mow MyLawn yard_of_grass with a
>SearsSpecial lawn_mower.
>
>Is that decent or what?
>It beats the heck out of asking a lawn to mow itself!

This is silly.  Does our hypothetical program have any
responsibilities that pertain to some real-world "lawn-mowing fools"?
Are there some real human beings out there that the software is
supposed to give orders to, telling them what lawns to mow with what
lawn mowers?  If so, then I suppose I could understand the need for a
"lawn_mowing_fool" class.  

But if the program itself is supposed to control the lawn mowers
*directly*, then inventing a lawn_mowing_fool class is just an
unnecessary complication.  The computer *itself* is supposed to be the
"lawn-mowing fool".  Or perhaps we've already had experience with a
non-computerized system in which "lawn-mowing fools" -- who sometimes
get "drunk" or "out of control" -- are employed to mow lawns.  Perhaps
we're actually trying to *replace* the "lawn-mowing fools" with
software that can do the job better.  If that's case, then imitating the
behavior of "lawn-mowing fools" in software would be not be "cool" or
"decent" -- it would be totally *foolish*. :-)

The point of this thread was that when you see a C++ member-function
call like:

    theFrontLawn.mowWith(theSearsSpecialMower);

or a Smalltalk method call like:

    theFrontLawn mowWith: theSearsSpecialMower.

you should never feel complled to imagine this as meaning "the front
lawn will mow itself using the Sears Special lawn mower".
Unfortunately, the syntax seems to encourage this kind of
interpretation, and a lot of people even *advocate* this kind of
thinking as being "cool".  However, I (today) believe this is a silly
way of interpreting what object-oriented software does.  Instead, I'd
read this kind of call as meaning "the part of the computer devoted to
the front lawn will mow it (the front lawn) using the Sears Special
lawn mower."  You always have to keep in mind that "theFrontLawn" is
just a chunk of *software* responsible for the front lawn -- and I
think "mowing the lawn" should be an integral part of its
responsibilities, not something off-loaded to another object.

The equivalent call in Ada95 might be something like:

    Lawns.Mow (The_Lawn   => The_Front_Lawn,
               With_Mower => The_Sears_Special_Mower);

(assuming "Lawns" is a package containing a tagged type "Lawn" with a
primitive procedure "Mow"). With this syntax, I'd wager you'd be much
less likely to view "The_Front_Lawn" as somehow "mowing itself".  Yet
this Ada subprogram-call might have exactly the same dynamic-
dispatching semantics as the C++ member function call or the Smalltalk
method invocation above.  That is, "The_Front_Lawn" might be a special
"controlling" parameter, whose run-time type information ("tag" in
Ada95 jargon) would determine which overloaded implementation of "Mow"
to dispatch to.

 >Mark S. Hathaway       <hathawa2@marshall.edu>

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Shameless_Controversial_Marketing_Slogan_For_Favorite_Language =>
      "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" &
      "Inheritance, hierarchical name-space, generic templates, type-safety, " &
      "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " &
      "multi-threading, distributed systems, real-time, safety-critical ...  " &
      "<< A d a 9 5  :  Y o u   n a m e   i t ,  i t ' s   i n   t h e r e >>",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------