Newsgroups: comp.object,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!news.oleane.net!oleane!pipex!uunet!rcm!rmartin
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Teaching OO
References: <D2150022.k0e90w@ed.bse.com>
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Tue, 17 Jan 1995 17:41:04 GMT
Message-ID: <1995Jan17.174104.4480@rcmcon.com>
Lines: 169
Xref: glinda.oz.cs.cmu.edu comp.object:25178 comp.lang.smalltalk:19615


>> rmartin said:
>> >>Nor is it possible to model the world in an OO context.  Only very
>> >>small pieces of the world are subject to such modeling.
>> 
>> >I think you will have an incredibly difficult time substantiating this,
>> >but I would like to see  an argument supporting it, rather than the
>> >bare assertion.
>> 
>> OK, model a human being in an OO context;  be accurate and complete.

ed@bse.com (Edward V. Berard) writes:

>People do this all the time. (Yes, I know what Robert really means,
>but let me proceed.) For example, I routinely work with people who
>want to model their business environment. These environments are full
>of such things as documents, departments, procedures, machines, and
>(yes) people. As with the geologist simulating a rock slide, these
>people want to create (static and dynamic) simulations of their
>business environments.  In their simulations, human being objects are
>represented as non-living, artificial objects.

>Of course, depending on your level of abstraction, and which particular
>aspects of the human being you want to model, your model of a human
>being in an object-oriented context can be quite complex. You can have
>anything from "a very limited static collection of information about a
>human being" to "a full-blown, very dynamic model of a human being
>built up from still smaller systems of interacting objects."

I have no problem with any of this so far.

>Yes, Robert has us at his mercy. Even if he accepts the fact that there
>can be different implementations of the concept of a human being (e.g.,
>"flesh and blood" implementations, and code software implementations),
>he can keep demanding progressively more detail, until we give up.

Thank you.  This was my point.  This "sub-thread" started when someone
made the assertion that the world was OO.  The world is not OO; all we
can do is create imperfect OO models of small parts of it.

>Still, in the end, what is important is how a human being object might
>be used (and, of course, reused) in multiple contexts. Most of us,
>I would guess, would be quite happy with a rather limited abstraction
>of a human being object. (In the spirit of reuse, we would very likely
>have a set of implementations of the human being object.)

Agreed.

>> >>The world is complicated.  OO can be used to manage some of that
>> >>complexity, in certain contexts. 
>> 
>> >Where does it fail?
>> 
>> It fails to model non-deterministic problems.  It is inefficient for
>> modeling very small problems.  It does not work well for modeling
>> problems which are comprised of many different little applications
>> operationg an a single huge reservoir of data.  There are probably
>> other scenarios as well.

>The answer to the question of "where does it [object-orientation] fail?",
>depends on one's training and experiences. For example:

>	- Any situation involving concurrency is non-deterministic.
>	  Given that many (if not all) telecommunications systems involve
>	  concurrency, these systems are non-deterministic. Yet, I
>	  know of many telecommunications applications that are implemented
>	  using an object-oriented approach. (For that matter, there
>	  are quite a few real-time object-oriented applications out
>	  there that involve non-deterministic situations.)

While it is helpful to look at concurrency as "non-deterministic", in
actual fact it is not.  The reason is simple, in a computer, time is
not a continuum, it is quantized.  Any program, even one with lots of
real time threads, can be "determined" if analyzed on a small enough
time scale. 

What I meant by "non-deterministic" was a problem for which there is
no algorithmic solution.  For example:  Find both the exact momentum
and position of an electron.  Or evaluate the *exact* value of pi.

I know these problems seem like cheating.  But the assertion that I
was challenging was that the world was OO.  I am simply providing
counter examples.

>	- For small problems, we are again at Robert's mercy. On one
>	  hand, Smalltalk programmers are quite fond of showing you
>	  just how fast they can create small working applications.
>	  On the other hand, Robert can keep shrinking the problem
>	  until it would be silly to use a compter to solve it at all.

Quite.  However this is not quite what I was getting at.  Some
applications that are not trivially simple, still will not benefit
from OOD.  Such applications must be small i.e. 2000-5000 lines, and
have a very limited lifetime.  For such applications the cost of OOD
will be high in comparison to the cost of functional decomposition.
Moreover, the long term benefits will not be achieved since the
lifetime is too small.  

Now notice, I said OOD, not OOP.  Yes, you can program this very
nicely in a language that has lots of established classes.  Smalltalk
would be a great candidate.  But this is not using OOD.  This is
simply performing a functional decomposition in the context of
Smalltalk's huge class library.  

Yes, you may wind up with some classes and objects and passing of
messages back and forth.  But, still, this is not OOD.  What is
lacking is the dilligent effort to create an OO model that has its
dependencies managed such that it will be reusable and maintainable.  

>	- Having designed an object-oriented solution to a classic
>	  "data warehouse" problem myself, I know that object-oriented
>	  approaches can work quite well "for modeling problems which
>	  which are comprised of many different little applications
>	  operating an a single huge reservoir of data." In fact, the
>	  object-oriented solution proved superior to an information
>	  engineering solution to the same problem.

A single case does not disprove the assertion.  Also, I did not say
that OO techniques could not be used in such domains.  However it will
*generally* not be possible to construct an OO model of the data. 

The reason is simple.  In such domains the data exists before the
applications.  There are an undefined number of applications that can
operate upon the data.  Some will be specified up front, but many
others will need to be written over time.  There will be no end to
these applications.  As long as the data exists, new ways of
manipulating it will be needed.  

Thus, it will be impossible to include the methods that operate upon
the data in an object model of the data.  In one sense, the object
model can never be completed.  One could continue to open the objects
and add methods, however this leads to unlimited code bloat within the
objects.  Nobody wants to link the code for every application into
their particular application.  So the code will have to be exported
out of the objects and into the applications.

Certainly there are some OO tricks that can be applied to the data.
The Visitor pattern a la Gamma is a nice approach.  However, that does
not change the fact that the data cannot be modeled as objects which
are tightly associated with the methods that operate upon them.  

Another way to look at this is that OO is the encapsulation of data
behind a behavioral interface.  What we know about an object are the
services that object can perform.  We should know nothing about the
data that the object contains.  Yet in a domain where the data is
central and the applications are unlimited, this view cannot be
maintained.  Since the methods that operate upon the data cannot be
placed within the objects that represent the data, the knowlede of the
data must be exported into the applications.  Thus we wind up with the
reverse of an object oriented design.  We wind up with data that has
no knowledge of the methods that operate upon it, and we wind up with
applications that operate upon, and have full knowledge of, the
structure of the data.

>I firmly believe that "none of us is as smart as all of us." Collectively,
>we have seen object-orientation used to solve an extremely wide variety
>of problems.

Of course.  However there is also no such thing as a magic bullet.  No
approach is going to be the perfect solution for *everything*.  OOD is
a great tool, and it can yeild wonderful benefits in a remarkable
number of problem domains.  But it does not solve everything, and
there are domains in which is is relatively useless.

-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++
