Teaching OO 
Author Message
 Teaching OO

Quote:

>My way of looking at it is that much of the learning in OO or any
>other paradigm in general has to do with *realising things yourself*
>than with being *taught*.

Absolutely true!  The work is done by the student, the teacher is
a facilitator -- in any true learning situation.

[snip]

Quote:
>You can do this only if you teach them how OO "rectifies" some of the
>problems in structured programming. Else it just becomes a question of
>accepting things like "objects are the way to go" just on the
>teacher's face value.

And here I must strenuously object --  one does *NOT* have to teach
why, how, or even whether OO "rectifies" problems present in some
other paradigm.  One 'merely' needs to show that it works.
And having shown that useful things can be done (in useful, pleasant, or
otherwise positively valued ways), one is no longer in the camp of
"its better because I, the almighty instructor, say so" or the camp of
"its better because it fixes these flaws that exist over there".  One is,
instead, in the camp that avoids unnecessary comparisons, and claims
merely "its good because it works."

[Two slightly off-the-wall bits from philosophy:  Comparisons are odious,
Aristotle.
Objects are that which object, the French existentialists...  (Ponder *that* one
next time you are teaching OO ;->  ]

Bill Felton
personal opinions only...
Vice President of Education
JumpStart Systems, Inc.
West Coast Office, Portland, OR
(503) 644-8820



Fri, 27 Jun 1997 23:41:01 GMT  
 Teaching OO

Quote:


>>>>But lets properly define OOD for the purposes of this conversation.
>>>>OOD is the use of abstract interfaces for the managment of
>>>>dependencies in a software application.  The end result of that
>>>>management is the creation of modules whose independence (gained by
>>>>managing dependencies) makes them reusable and maintainable.  

Bill Said:

Quote:
>>>I would submit that this is a highly unusual, and virtually useless
>>>(outside academia and camp-follower seminar'ing) definition.  OOD
>>>is designing software using objects.  To reduce that (or is it to
>>>overly-complexify it?) to the point where objects are consdered
>>>solely as intefaces, and then only from the point of view of
>>>abstractions, is to engage in a type of theorizing of no use
>>>whatsoever to those attempting to deliver solutions to business.

Bob Said:

Quote:
>> That is quite a claim.  I think you would find it hard to
>>substantiate.
>>Consider.  What makes a class reusable?  A reusable class is a class
>>which can be removed from the context for which it was designed and
>>inserted, unchanged, into a new context.  In order to achieve this,
>>the reusable class *must not depend* upon any of the details in the
>>original context.  Thus, the dependencies of that class must be
>>managed.

Bill Said:

Quote:
>Well, I have at least as much trouble with this as I do with the
>proposed definition of OOD.  First off, the focus of OO is not and
>ought not to be, reuse.  It had better be on use, or reuse will not
>and cannot happen.  For an object to be reusable is certainly a plus,
>but it is NOT the sine qua non of OO.  Far from it.  

And I think that this is part of the problem with many software
systems today.  The focus of the software was only upon the "here and
now" and not enough attention was paid to what might happen down the
road.    

Designing for reuse is more complex than simply making a bunch of
components that others might be able to use one day.  Designing for
reuse is to admit that the software you are producing has a lifecycle
that it must survive.  If one focuses only upon "use" as you suggest,
then the code you produce will become unmaintainable in a short time.
However, if one focuses upon "reuse", then the code will be reusable
in its current context during the maintenance cycle.

Remember, maintenance is a form of reuse, since you are changing the
application and then asserting that all the unchanged code can be
reused in the changed context.

Quote:
>Secondly, the
>notion that in order to be reusable an object must able to be yanked
>bleeding out of its original context and plugged willy-nilly into any
>old other context and function -- or it is not a reusable class -- is
>nonsense.  

I never said, or implied that.  A class is reusable if it can be used,
unchanged, in more than one detailed context.

Quote:
>I agree that one must understand the boundaries of
>the contexts within which an object can usefully play a role -- and
>that this may well involve managing the interface (and
>implementation) of the object(s) in question.  But I do not believe
>that these are core issues, let alone core OO design issues.

What do you believe are the core design issues?  

Quote:
>>If A is the class we want to reuse, and B is a class in the original
>>context, and if instances of A must send X messages to instances of B,
>>then how can be make A reusable?  By creating a new class AbstractB
>>which has X defined as a pure interface.  Now A can send X messages to
>>AbstractB, not to B directly.  B derives from AbstractB and so can
>>receive the X message.
>However, given the existence of bounded contexts, there is no such
>thing as "pure" or 'abstract' interface with no dependance whatsoever
>on implementation.  

Of course there is.  

class AbstractB
{
  public:
   virtual void X() = 0;

Quote:
};

The class AbstractB has utterly no dependency at all upon any
potential implementation of X in a derived class.

Quote:
>Further, the practical overhead of "pure
>interface" classes and objects is too high a price to pay for the
>purported reusability of some of the objects which will play roles in
>"commercial" sofware [defined as software for which someone other
>than the developer is willing to pay for development, and with the
>notion that the end result will be usable].

The cost of managing dependencies with abstract interfaces *is* high.
So the benefits better be there to offset the costs.  The benefits are
that the modules within the application are not interdependent.  When
changes are made in one module, they do not propogate to others.  Bugs
can be fixed, and features added, without introducing lots of new bugs
in unrelated parts of the code.

Quote:
>>When A is resused in a new context, a new derivative of AbstractB will
>>need to be created, one that is germane to the new context.

>>Now, note.  The existence of AbstractB, which is essential to the
>>ability to reuse A, is not required at all for the original
>>application.  It is not until one considers reuse that one would
>>design AbstractB into the solution.
>And this is, in its heart, my argument against your definition of OOD
>-- we must design usable objects before we can worry about reuse.
>Reuse is important, but it is not the whole story, nor the central
>theme of the tale.  Further, and most problematic, your definition is
>of no use whatsoever in the design of usable objects.  Because of its
>single-minded focus on reuse, it misses the tree in service of the
>forest.

We can use Structured Analysis and Design to create modules that can
be "used".  But, as history has shown, we need something more.  Not
only must modules be usable, they must be maintainable.  They must
survive their lifecycle.  And this means that we have to design the
modules for survivability.  One very important criterion is the
management of dependencies between modules.  A module with very few
dependencies is more robust than a module with many dependencies.  

Quote:
>>What is
>>the goal of OOD?  What benefits are we trying to gain.  
>How to design useful objects.  

Why objects?  Why not just useful code?

Quote:
>The benefits of encapsulation,

What are the benefits of encapsulation, if not the management of
dependency?

Quote:
>inheritance, polymorphism,

Why these two?  You have named mechanisms but no motivation.  Why do
you name inheritance and polymorphism as benefits and goals?

Quote:
>and, yes, reuse.  But reuse last.

I disagree.

--
Robert Martin       | Design Consulting   | Training courses offered:

2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++



Sun, 29 Jun 1997 22:34:49 GMT  
 Teaching OO


[snip]

    >> You can do this only if you teach them how OO "rectifies" some of the
    >> problems in structured programming. Else it just becomes a question of
    >> accepting things like "objects are the way to go" just on the
    >> teacher's face value.

    bfelton> And here I must strenuously object --  one does *NOT* have to teach
    bfelton> why, how, or even whether OO "rectifies" problems present in some
    bfelton> other paradigm.  One 'merely' needs to show that it works.

And what do you mean by "works"? That's one hell of a relative term.
SA/SD "worked" too! The point lies in OO being a *better* paradigm.

Okay assuming students are going to be taught OO as the first paradigm
with no exposure to structured development I see a few problems:

1. Isn't there a chance of them accidentally using a non-OO technique
which is bad? They'll tend to do that because they didn't know *what*
was bad about it.

2. The world is not OO; one needs enough background to make
intelligent choices (and there are no readymade recipes) when choosing
tools and paradigms.

I've heard that the CS Dept, Carleton University in Canada uses (or
maybe used) Smalltalk as the first language. Anyone care to share some
experiences?

    bfelton> And having shown that useful things can be done (in useful, pleasant, or
    bfelton> otherwise positively valued ways), one is no longer in the camp of
    bfelton> "its better because I, the almighty instructor, say so" or the camp of
    bfelton> "its better because it fixes these flaws that exist over there".  One is,
    bfelton> instead, in the camp that avoids unnecessary comparisons, and claims
    bfelton> merely "its good because it works."

    bfelton> [Two slightly off-the-wall bits from philosophy:  Comparisons are odious,
    bfelton> Aristotle.

Any reasons why you are so anti-comparative?

    bfelton> Objects are that which object, the French existentialists...  (Ponder *that* one
    bfelton> next time you are teaching OO ;->  ]

    bfelton> Bill Felton
    bfelton> personal opinions only...
    bfelton> Vice President of Education
    bfelton> JumpStart Systems, Inc.
    bfelton> West Coast Office, Portland, OR
    bfelton> (503) 644-8820

--
Cheers,
Anil
___________________________________________________________________________
Anil K Vijendran|             W W W               |USL Box 43007



Tue, 01 Jul 1997 08:10:00 GMT  
 Teaching OO

Quote:



 ...
> Bill Said:
 ...
> Bob Said:
 ...
> Bill Said:

 ...
[Bob saith]

Quote:
> Remember, maintenance is a form of reuse, since you are changing the
> application and then asserting that all the unchanged code can be
> reused in the changed context.
  ...
> >>What is
> >>the goal of OOD?  What benefits are we trying to gain.  

> >How to design useful objects.  

> Why objects?  Why not just useful code?

> >The benefits of encapsulation,

> What are the benefits of encapsulation, if not the management of
> dependency?

> >inheritance, polymorphism,

> Why these two?  You have named mechanisms but no motivation.  Why do
> you name inheritance and polymorphism as benefits and goals?

Let's put it in a different way: Malleable and reusable code ought
to be the goal.  The means to these include separation of concerns,
encapsulation, decoupling, achievement of high cohesion, etc.

Inheritance and various kinds of polymorphism are means to _those_.

Quote:
> >and, yes, reuse.  But reuse last.

As Bob states, the first form of re-use is re-use in the next release.

Believe it!  If your code can't pass this test for re-use, it won't pass
many other tests.
--
 (This man's opinions are his own.)
 From mole-end                          Mark Terribile

        (Training and consulting in C, C++, UNIX, etc.)



Tue, 01 Jul 1997 14:07:35 GMT  
 Teaching OO
Robert,

I've been reading this thread for some time now and I have a number of
concerns on how you approach OO.  First let me provide a context.  I see OO
as a "revolutionary evolution".  In SA/D we spent our time deciding:
        what to do?
        what to do it to?, and
        where to do it?

These tasks lead us through DFD's and structure charts, and these method(s)
have served us well.  OO has the same tasks (the evolution), but the focus is
on the "thing", not on the "process".  In OO:
        what is it?
        what does it contain?, and
        what do we do to it?

This is a fundamental change in how we approach a problem (revolution!).  
We no longer use the "process" as the beginning of a design, we identify the
"things" we need to worry about in the problem domain first.  

Many analysis tools (like Jacobson's Use Cases) use process focused
techniques to identify objects, but , IMHO, once the objects are identified
(what is it?) the next two steps come in order.  This implies that the "program"
part (that part of the system that manipulates the objects to solve specific
requirements in the problem domain) of the solution is ignored.  Domain
object construction focuses only on what this object has to provide the system
to satisfy it's own duties (requirements).  This enhances the probability of
being able to reuse these domain objects for different specific solutions within
the whole domain, not just this particular solution.

This approach is not a single (waterfall) pass but is iterative in that when you
start dealing with the contents and methods, new objects may surface,
additional peer objects may need to be created (like the sets of objects
described in a earlier post), and additional hierarchy changes may be exposed.

The program part of a systems only goal is to provide a context in which the
objects will be used.  This context is the formal solution to the particular
problem within the domain defined by the requirements given for the system.

With that as a very simplified context:

Quote:
>Date: Thu, 5 Jan 1995 23:13:35 GMT

>Detail first IMHO.  Binary, simple logic, flow charts, etc.  Then
>Knuth's Fundemental Algorithms.  Then Wirth's Algorithms + Data
>Structures = Programs.  Then Demarco's Structure Analysis and
>Page-Jones' Structured Design.   Then Booch or Rumbaugh, OOD.  And
>many other steps in between.

Here I agree except that I would switch OOD with SA/D.  I believe SA/D
techniques are very power tools for flushing out the methods defined for a
particular object.  In using them we can identify internal objects that may not
have been identified yet as a part of the iterative process.  But I don't
believe teaching SA/D first is as useful as establishing a strong OO floor on
which to build OOA, OOD, and then SA/D.

Quote:
>Date: Thu, 5 Jan 1995 23:23:48 GMT

>SADP is not simpler than OOAD, because OOAD subsumes SADP and then
>adds.  All the same rules of SADP apply to OOAD, and then more are
>added.  

This may be true for implementation languages like C++, but I disagree that
all the same rules apply.  SA/D demanded that the process space that solved
the problem in the domain be analyzed and defined in procedural terms first.  
This just is not the way, IMHO, OO should be tackled.  I first want to ID the
"things", not the "processes", that's last.

Quote:
>Date: Fri, 6 Jan 1995 22:36:37 GMT

>SD produces high level policies that depend upon the details that they
>control.  This is evident in a structure chart.  The high level policy
>laden functions must call the low level detail laden functions.

>In OOD, the opposite is true, the low level detailed classes depend
>upon the high level abtract classes that set the policies.  This is
>"dependency inversion" and it is at the heart of OOD.

This is profound!  OOA will define abstract things that make up the problem
domain.  OOD will refine this abstract world and give it form.  This process
produces a design that achieves "dependency inversion" while preserving the
abstractions that define the problem domain and the solution that manipulates
the classes to fulfill the requirements for the specific problem within the
domain.

Quote:
>Date: Fri, 6 Jan 1995 22:50:53 GMT

>Usually the benefits of OOD outweigh the costs.  But not in every
>case.  There will always be applications that have short lifetimes, or
>limited deployment that could never recapture the costs of OOD and are
>better off being developed using SA/SD.

This is just flat wrong.  I can still (and do) produce better, more error free
solutions using OO techniques.  For systems I -know- will be short lived, I
may not spend as much time analyzing the hierarchy, designing for reuse, or
adjusting objects for a more polymorphic fit.  But even if I do nothing but
apply encapsulation - I will have a better system than SA/D alone will give
me.

Quote:
>Date: Thu, 29 Dec 1994 13:42:27 GMT

>>I allways thought to model an object you
>>1. name the object
>>2. describe its structure [variables/attributs]
>>3.      and its _potential_ behavior [methods]
>>4. describe its _actual_ behavior [state(transition)s]
>Flip a few of these:
>1. Ascertain that a certain behavior exists
>2. Assign it to an appropriate object.
>3. Create the state machine for the object
>4. Implement the object.
>    4a. Determine a workable data structure
>    4b. implement the state machine.

I see this as an interesting mix of OO and SA/D.  How do you assign a
behavior that is complex and uses several potential peer objects?  How can
you assign the behavior to an object if the objects are not defined yet?  How
do you know what behaviors are needed until the attributes are identified?  
Who owns the behavior you start with?  In what context does the behavior
exist?

I like the above's addition of breaking behavior into potential and actual.  This
helps the designer to think about the object in the whole domain, not just the
segment of the domain that contains this systems particular solution.  This
helps the designer to construct the object to satisfy the current requirements
without interfering with anticipated functionality.  Hopefully this will keep her
from stepping on any toes in the future - again, enhancing reuse.

...gene

Eugene Dowen..............| Information Systems and Business Consultants
TASS Independent, Inc.....|
1015 South Gaylord Street.| From Business Process Reengineering to
Suite 136.................| Wide Area Networks to
Denver, CO 80209..........| Front Office and Back Office Automation:
1-800-965-TASS............| TASS Independent makes it happen!



Tue, 01 Jul 1997 22:58:30 GMT  
 Teaching OO

Quote:



>[snip]

>    >> You can do this only if you teach them how OO "rectifies" some of the
>    >> problems in structured programming. Else it just becomes a question of
>    >> accepting things like "objects are the way to go" just on the
>    >> teacher's face value.

>    bfelton> And here I must strenuously object --  one does *NOT* have to teach
>    bfelton> why, how, or even whether OO "rectifies" problems present in some
>    bfelton> other paradigm.  One 'merely' needs to show that it works.

>And what do you mean by "works"? That's one hell of a relative term.
>SA/SD "worked" too! The point lies in OO being a *better* paradigm.

We were speaking of motivating students to learn OO.  And I still believe
that no other motivation is necessary than demonstrating that one can
"do things" with OO, ie, solve computational problems.  That is
sufficient, one need not show that it solves problems that other
approaches to computation cannot solve, or solve only with difficulty.
THAT was, and remains, my objection to the 'comparison' of OO and
other approaches.

Quote:
>Okay assuming students are going to be taught OO as the first paradigm
>with no exposure to structured development I see a few problems:

>1. Isn't there a chance of them accidentally using a non-OO technique
>which is bad? They'll tend to do that because they didn't know *what*
>was bad about it.

I really do not understand what you might have in mind here.  Contrary to
most of the zealotry and evangelizing that goes on, OO is a procedural
discipline, code is written using algorithms, data structures, and all
the other "low level" notions of programming.  It is encapsulated, packaged
if you will, differently, it is conceptualized differently, it is approached
differently, but the foundations remain the same.  And to teach people
to program with OO is, fundamentally, to teach people to program.d
Just as one does not need to learn Basic in order to learn Pascal, or Pascal
in order to learn C, I believe that one does not need to learn the elaborated
theoretical frameworks of the past in order to be introduced to programming
with objects.  Certainly, one can avoide the "goto" heresies trivially in a
fully OO language ;->

Quote:
>2. The world is not OO; one needs enough background to make
>intelligent choices (and there are no readymade recipes) when choosing
>tools and paradigms.

Within limits, I agree.  But we are speaking of teaching beginning programmers
OO.  And we were speaking about the need for them to have learned about
the prior approaches *before* being exposed to OO.  I disagree with that,
and, apparently, so does:

Quote:
>... the CS Dept, Carleton University in Canada uses (or
>maybe used) Smalltalk as the first language. Anyone care to share some
>experiences?

Anecdotal remarks indicate it has been very successful.  Certainly, the
graduates are having no problems finding work ;->

Bill Felton
personal opinions only...
Vice President of Education
JumpStart Systems, Inc.         Suite 813, 515 NW Saltzman Road
West Coast Office,                      Portland, OR  97229
(503) 644-8820



Wed, 02 Jul 1997 00:06:14 GMT  
 Teaching OO

Quote:

>As Bob states, the first form of re-use is re-use in the next release.

>Believe it!  If your code can't pass this test for re-use, it won't pass
>many other tests.

But it won't even *get* to that test if it isn't usable.  And I have seen
too many cases of people being so concerned with reuse that they never
complete a design, let alone implement and deliver...  (really!)
And to make the claim that OOD is about reuse is to leave the person
*beginning* a project, or a design, dead in the water before they begin.
Before I can worry about reuse, I must worry about use.  I must know
how to design networks of collaborating objects.  I can then begin
to worry about reuse issues.  But those issues are properly secondary.
Use precedes reuse, just as design precedes implementation.
WIthout a set of design guidelines for building usable objects, we
have no basis for developing a set of design guidelines for
identifying, let alone designing, reusable objects.  (And not all useful
objects are reusable, nor need they be, except in the highly watered
down sense of maintenance upgrades.  And if they were correctly
designed and useful in the first place, they may never need to be
redesigned, or "maintained" in order to maintain their utility...)

I would really like to suggest that we have reached a point where
the discussion is fragmenting -- and in large measure the disagreements
have been over emphasis rather than fundamentals.  My disagreement
with Mr. Martin is not over whether reuse is a good thing (it is) or
whether objects represent a good and useful way to develop software
(they are).  My disagreement is with the *emphasis* on reuse as the
primary focus of OO design, coupled with what I felt, and still feel, to be
a highly idiosyncratic, and ultimately abstracted to the point of uselessness,
defintion of OOD.  I still fail to see how the definition Mr. Martin provided
gives any guidance or support to those beginning to design objects.
If he had presented his definition as  "OORE (oo reuse engineering)" or
some other name, I would likely have sat out the discussion (despite my
strong feeling that OO is not an advanced topic to be introduced only
late in the education of programmers).

Bill Felton
personal opinions only...
Vice President of Education
JumpStart Systems, Inc.
West Coast office               suite 813, 515 NW Saltzman Road
(503) 644-8820                  Portland, OR  97229



Wed, 02 Jul 1997 00:16:41 GMT  
 Teaching OO

Quote:
>Robert,

>I've been reading this thread for some time now and I have a number of
>concerns on how you approach OO.  First let me provide a context.  I see OO
>as a "revolutionary evolution".  In SA/D we spent our time deciding:
>    what to do?
>    what to do it to?, and
>    where to do it?

>These tasks lead us through DFD's and structure charts, and these method(s)
>have served us well.  OO has the same tasks (the evolution), but the focus is
>on the "thing", not on the "process".  In OO:
>    what is it?
>    what does it contain?, and
>    what do we do to it?

I could not have put it better myself (obviously!).
I would, however, suggest that the third point might be better expressed
as "what does it do for us?" (object as active) rather than the
way you have phrased it (which suggest the object as the passive
subject of external acts...).

Quote:
>This is a fundamental change in how we approach a problem (revolution!).  
>We no longer use the "process" as the beginning of a design, we identify the
>"things" we need to worry about in the problem domain first.  

Absolutely!  As Jeff McKenna put it some years ago when I was
privileged to work on a project with him:
What we do in OO is build ecologies of collaborating objects.
This metaphor has proven very powerful, both for me and for my
students...

[remainder snipped, despite its value and correctness ;-> ]

Bill Felton
Vice President of Education
JumpStart Systems
West Coast office               suite 813, 515 NW Saltzman Road
(503) 644-8820                  Portland, OR  97229



Wed, 02 Jul 1997 00:23:23 GMT  
 Teaching OO

Quote:


[snip]
>>I have no objection if beginning students are taught to fiddle with
>>OOPLs.  But the principles of OOD, i.e. the management of
>>dependencies, will not be properly understood without the proper
>>context.

>I would dispute that. As you say in another thread, the important difference
>between Data Abstraction and OOD that allows dependencies between modules to
>be broken, is the use of abstract interfaces (or protocols, or whatever you
>want to call them). New OO programmers can be immersed in that from day 1.
>So where is the problem?

>Perhaps beginning students will not appreciate just how bad previous approaches
>were at managing dependency. Is that any great hardship? I don't have to learn
>the ins and outs of using vacuum tubes before I can use a knowledge of
>transistors. I know that transistors are smaller, faster, more energy-
>efficient, etc., and that is all I need.

I strongly agree with Mr. Hopwood.  Not only does this map much more
realistically on to my own experience with electronics, but I think it
exposes one of the central problems I have with Mr. Martin's views:
One will *never* proceed beyond "fiddling" with OOPL's if one does
not have some design guidelines to go by.
To assert that all there is to OOD is "dependency management" is to miss
a number of useful OO design guidelines.
And I can see no bridge between "fiddling with OOPL's" and learning
the importance of managing dependencies, and designing for reuse
in a design model that focuses solely on managing dependencies.
I believe that OO design is a good way [the only way] to introduce
rigor and engineering practice in the utilization of OO languages.
One does not begin teaching the rigors of dependency management
and broad reusability at the beginning, any more than one teaches
calculus to people who have not yet had algebra.  But one does not
teach that "calculus is the only mathematics" and provide no education
in the mathematics of algebra (and arithmetic) to those who will eventually
need calculus.  Instead, one teaches arithemtic, algebra, geometry, trig, etc.
and expects those to be done correctly and in a principled fashion *in order
to proced to ever higher degrees of math*.  I see the situation with OO,
and OO Design as very analogous to this.  Just because there are great
depths and fine subtleties in dependancy management does not mean
that it is the only OOD worthy of the name -- nor that nothing else should
be taught under that rubric.
Let *stop* people "fooling around" with OOPL's and teach them instead
how to design objects and networks of interacting objects, and then
how to improve them as they learn more and more of the context.

Bill Felton
personal opinions only...
Vice President of Education
JumpStart Systems, Inc.
West Coast office               suite 813, 515 NW Saltzman Road
(503) 644-8820                  Portland, OR  97229



Wed, 02 Jul 1997 00:38:46 GMT  
 Teaching OO

[snip]

Quote:
>If the world looks OO to you, then you have a very simplistic view of
>the world.  

What does the world look like to you?  It sure looks like objects to me...
How is this simplistic?  Any of the significant philosophies have been
essentiall "object oriented" (saving perhaps only Bergson and Whitehead,
who were significantly process oriented...)

Quote:
>An "object" in a piece of OO software has very little to do with an
>object in the real world.  The software object is a highly imperfect
>model.  

Then its highly imperfect software, modulo the needs of the programming
context.  An object in a piece of OO software had *better* have
quite a great deal to do with all relevant aspects of the object in
the world that is being modeled.  Or the software fails.

Quote:
>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.

Quote:
>The world is complicated.  OO can be used to manage some of that
>complexity, in certain contexts.

Where does it fail?

Bill Felton
strictly personal opinions...



Wed, 02 Jul 1997 00:46:42 GMT  
 Teaching OO

Quote:

> ...

> Bill Said:
> >Well, I have at least as much trouble with this as I do with the
> >proposed definition of OOD.  First off, the focus of OO is not and
> >ought not to be, reuse.  It had better be on use, or reuse will not
> >and cannot happen.  For an object to be reusable is certainly a plus,
> >but it is NOT the sine qua non of OO.  Far from it.  

> And I think that this is part of the problem with many software
> systems today.  The focus of the software was only upon the "here and
> now" and not enough attention was paid to what might happen down the
> road.    

> Designing for reuse is more complex than simply making a bunch of
> components that others might be able to use one day.  Designing for
> reuse is to admit that the software you are producing has a lifecycle
> that it must survive.  If one focuses only upon "use" as you suggest,
> then the code you produce will become unmaintainable in a short time.
> However, if one focuses upon "reuse", then the code will be reusable
> in its current context during the maintenance cycle.

Having worked on projects where a lot of effort was placed on planning
for possible future needs, OO and structured, i agree with Bill.
Somewhere in some OO journal i read a statement to the effect that we
are in general very bad at predicting future requirements.  Good OO
design satisfies the existing needs. Reuse is not an objective of OO
design.  It is instead a benefit of good OO design.

If you design for reuse you are likely to end up with a lot of very
general and poorly defined objects that sort of work for most people
but don't really adequately satisfy anyone's particular needs.  In a
good OO design the objects defined meet the needs of that particular
set of requirements.  The reuse appears afterword, on its own,
unplanned for.

Quote:
> Remember, maintenance is a form of reuse, since you are changing the
> application and then asserting that all the unchanged code can be
> reused in the changed context.

Seeing maintenance as reuse is, i think, an overly broad definition of
reuse and not an entirely accurate definition of maintenance.

Quote:
> >Secondly, the
> >notion that in order to be reusable an object must able to be yanked
> >bleeding out of its original context and plugged willy-nilly into any
> >old other context and function -- or it is not a reusable class -- is
> >nonsense.  

> I never said, or implied that.  A class is reusable if it can be used,
> unchanged, in more than one detailed context.

A class is reusable if it can be inherited from to meet the needs of
similar, but not necessarily identical, environments.  But that reuse
can only be determined by the later development, not by the original
development of the class.  Not all classes need to be reused and a class
should not be designed for reuse until there is a demonstrated need.

- Show quoted text -

Quote:
> ...

> >However, given the existence of bounded contexts, there is no such
> >thing as "pure" or 'abstract' interface with no dependance whatsoever
> >on implementation.  

> Of course there is.  

> class AbstractB
> {
>   public:
>    virtual void X() = 0;
> };

> The class AbstractB has utterly no dependency at all upon any
> potential implementation of X in a derived class.

Not being knowledgeable in C++ i have to ask - what use does this
class serve?  I get the feeling that, by your definitions, a perfect
class would define objects that provided no services - how is it possible
for an object to provide services without those services being needed
in and determined by the context where the object lives?

- Show quoted text -

Quote:
> ...
> >And this is, in its heart, my argument against your definition of OOD
> >-- we must design usable objects before we can worry about reuse.
> >Reuse is important, but it is not the whole story, nor the central
> >theme of the tale.  Further, and most problematic, your definition is
> >of no use whatsoever in the design of usable objects.  Because of its
> >single-minded focus on reuse, it misses the tree in service of the
> >forest.

> We can use Structured Analysis and Design to create modules that can
> be "used".  But, as history has shown, we need something more.  Not
> only must modules be usable, they must be maintainable.  They must
> survive their lifecycle.  And this means that we have to design the
> modules for survivability.  One very important criterion is the
> management of dependencies between modules.  A module with very few
> dependencies is more robust than a module with many dependencies.  

Yes, encapsulation is good, but this does not require that the
object be designed for reuse.  It simply requires that the object
be well-defined.

Quote:
> >>What is
> >>the goal of OOD?  What benefits are we trying to gain.  

> >How to design useful objects.  

> Why objects?  Why not just useful code?

> >The benefits of encapsulation,

> What are the benefits of encapsulation, if not the management of
> dependency?

> >inheritance, polymorphism,

Inheritance and polymorphism are where the reuse comes from,
not from the "management of dependencies between modules."

Quote:
> Why these two?  You have named mechanisms but no motivation.  Why do
> you name inheritance and polymorphism as benefits and goals?

> >and, yes, reuse.  But reuse last.

> I disagree.

Reuse is finding an existing object that provides services very similar
to the services an object in your design needs.  You then either use
that class definition, inherit from that class definition, or define
an more general class that contains the commonality between your new
class and the old one and inherit from that.  But this is chronologically
late in the design - coming after the objects for a design are mostly
defined.  It is also, in my opinion, the least important aspect of OO
design.

Designing for reuse is, i think, very dangerous.

--

my opinions are my own



Mon, 30 Jun 1997 00:20:51 GMT  
 Teaching OO

Quote:

>Having worked on projects where a lot of effort was placed on planning
>for possible future needs, OO and structured, i agree with Bill.
>Somewhere in some OO journal i read a statement to the effect that we
>are in general very bad at predicting future requirements.  Good OO
>design satisfies the existing needs. Reuse is not an objective of OO
>design.  It is instead a benefit of good OO design.
>If you design for reuse you are likely to end up with a lot of very
>general and poorly defined objects that sort of work for most people
>but don't really adequately satisfy anyone's particular needs.  In a
>good OO design the objects defined meet the needs of that particular
>set of requirements.  The reuse appears afterword, on its own,
>unplanned for.

It is true that if you make a design based on how you imagine the
future might be, you will end up with a lot of overly general objects.
I call that "premature generality".  But that is not how you design
for reuse.  The way that you design for reuse is to take a range of
programs that you want to be able to build out of a set of objects
and to design the objects to meet the needs of those programs.  If
you have picked a decent set of target programs then you will end up
with a reusable set of objects.  

In general, software never has any good properties by accident.
Murphy's law, I guess.  It will only have good  properties that you
make sure it has.  In particular, you won't end up with reusable
OO software by accident.  Sure, inheritance means you can hack up
a component by overriding anything that doesn't fit (unless they
weren't virtual function!), but the result won't be easy to understand
or maintain.  Polymorphism requires standard interfaces, and it is not
easy to design interfaces powerful enough so that clients don't need to
extend them but simple enough that you can make a lot of different
implementations of them.

Quote:
>> >-- we must design usable objects before we can worry about reuse.

You must design objects that are *both* usable and reusable.  The
more requirements your design must meet, the harder it is to make it,
which is why it is so hard to write reusable software.  But things
that are valuable are often expensive.

I teach a course on "how to design frameworks" that explains all this
in more detail.  Some of the material is in papers that I've written
that you can get from ftp://st.cs.uiuc.edu/pub/papers.

-Ralph Johnson



Fri, 04 Jul 1997 04:49:20 GMT  
 Teaching OO

Quote:
> Having worked on projects where a lot of effort was placed on planning
> for possible future needs, OO and structured, i agree with Bill.
> Somewhere in some OO journal i read a statement to the effect that we
> are in general very bad at predicting future requirements....

Moral: don't believe everything you read in OO journals.

Quote:
> Designing for reuse is, i think, very dangerous.

I disagree, but it depends on the circumstances.  An example: we were
tasked to develop two OODB applications at about the same time (the
smaller of the two applications to be delivered sooner).  So we designed
a subset of the functionality to be reusable in a fairly general way for
OODB applications, and especially for those using the same OODB we were
(or a similar one).  We got immediate reuse of this core between the two
applications we were delivering, and by demonstration, we proved it can
be reused again for similar applications.


Fri, 04 Jul 1997 23:52:45 GMT  
 Teaching OO


Quote:


> >What does the world look like to you?  It sure looks like objects to me...
> >How is this simplistic?  Any of the significant philosophies have been
> >essentiall "object oriented" (saving perhaps only Bergson and Whitehead,
> >who were significantly process oriented...)

> It is easier for me to describe what the world does *not* look like to
> me.  It does *not* look like a collection of data structures and
> algorithms passing messages to each other through polymorphic abstract
> interfaces.  I cannot completely describe a "rock" for example, as a
> set of interfaces, data structures, and algorithms.

I think I see a possible reason for this "problem." In teaching object-oriented
concepts, I stress the difference between concepts implementations,
and views. A concept is our intellectual (usually non-software) understanding
of an item. (You could even say that a "concept" is an abstraction.)
For example, a Gregorian date is a means of identifying a specific
24-hour period in time using the western Christian calendar as a frame
of reference. We usually think of Gregorian dates as a tuple, containing
a year, a month within that year, and a day within that month. Months
are usually thought of as having distinct names, whereas years and
days are usually expressed using positive whole numbers.

A code software implementation of a Gregorian date could consist of
some structure containing a month object, a day object, and a month
object. Also encapsulated within this code software implementation
would be a set of methods for getting and setting the states of the
month, day, and  year objects, and an exception that would be raised
if there was an attempt to cause a Gregorian date to take on an invalid
state.

A view of a Gregorian date would be a string of characters representing
the state of the date. This string would appear in the upper left hand
corner of a window, and would be in 12 point Helvetica font, and reflex
blue in color. The string would contain an integer value that represented
the day, followed by a space, followed by the name of the month in
English fully spelled out with its first letter capitalized, followed
by a space, followed by the year represented as a four digit integer.

One concept may have many many different implementations, and each
implementation may have many different views.

When Robert says "I cannot completely describe a 'rock,' for example, as a
set of interfaces, data structures, and algorithms." What he is really
saying is that it is difficult for him to see the concept of a rock
implemented in code software, but it is easy for him to see the concept
of a rock implemented as a non-living set of chemicals that is relatively hard,
and whose shape is fairly static.

We would usually not think of a computer interacting directly with
a rock. (Indirect interactions, are of course, quite possible, e.g.,
as in a set of computer software that controls the activities within
a quarry.)

However, suppose one was a geologist wishing to create a computer simulation
of a rock slide, or wishing to model the impact of weathering on an
exposed rock face. In these situations, one would very likely create
another implementation of the concept of a rock. In effect, we would
create (one or more) software implementations of the concept of a rock.
If we were doing our simulations using an object-oriented approach,
then it would be entirely possible for us to create a "software rock
object" complete with "a collection of data structures and algorithms
passing messages to each other through polymorphic abstract interfaces."

Problems arise when we insist that all concepts have only one implementation.

Quote:
> 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.

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."

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 {*filter*}" implementations, and code software implementations),
he can keep demanding progressively more detail, until we give up.

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.)

Quote:
> >>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.)

        - 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.

        - 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.

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.

                                -- Ed

P.S.: Robert, thank you for letting me comment on this tread.

----------------------------------------------------------------------------
Edward V. Berard                                | Phone: (301) 417-9884
Berard Software Engineering, Inc.               | FAX:   (301) 417-0021

Gaithersburg, Maryland 20878                    |
****** Object-Oriented Training, Consulting, Mentoring, and Products *******



Fri, 04 Jul 1997 22:54:27 GMT  
 Teaching OO

Quote:

>Having worked on projects where a lot of effort was placed on planning
>for possible future needs, OO and structured, i agree with Bill.
>Somewhere in some OO journal i read a statement to the effect that we
>are in general very bad at predicting future requirements.  Good OO
>design satisfies the existing needs. Reuse is not an objective of OO
>design.  It is instead a benefit of good OO design.

I agree with the sentiment, but not the statement.  Design for "use"
is, of course, paramount.  However, neglecting reuse would be
unfortunate.

More importantly, designing for "use" does not simply mean "make the
application work".  It also means "Ensure that the application is
maintainable throughout its lifecycle, and is easy to adapt and expand
as its environment and market change."  Satisfying these needs
requires the same kind of thought and activities as designing for
reuse.  

As engineers, we must make a trade off.  Although maximal reusability
would be wonderful, it will be expensive.  On the otherhand, minmal
reusability will create applications that cannot be maintained or
enhanced.  We must strike a balance in the middle.  We must (as poor
as we are at it) attempt to predict the most likely forces that will
cause the software to change, and then design for reusability within
that context so that the architecture of the product is not affected
by those changes.

Quote:
>If you design for reuse you are likely to end up with a lot of very
>general and poorly defined objects that sort of work for most people
>but don't really adequately satisfy anyone's particular needs.  

This is only if you go mad with reuse and try to create classes which
are all things to all people.  But if you narrow your scope and try to
make objects that are reusable in the most likely context, you are
more likely to succeed.

Quote:
>In a
>good OO design the objects defined meet the needs of that particular
>set of requirements.  The reuse appears afterword, on its own,
>unplanned for.

No.  Unequivocally, No.  Accidental reuse is very rare, and is
generally unsatisfactory.  Simply writing code in an OOPL does not
guarantee any kind of reuse.  If reuse (and that included
maintainability and enhancability, since that is just reuse in place)
is to be achieved, it must be designed in.  The dependencies that
would thwart it, must be managed.

Quote:
>> Remember, maintenance is a form of reuse, since you are changing the
>> application and then asserting that all the unchanged code can be
>> reused in the changed context.

>Seeing maintenance as reuse is, i think, an overly broad definition of
>reuse and not an entirely accurate definition of maintenance.

Maintenance, and reuse have this in common, that they are both
thwarted by source code dependencies, and that they are both enhanced
by the management of those dependencies.  

Quote:
>A class is reusable if it can be inherited from to meet the needs of
>similar, but not necessarily identical, environments.  But that reuse
>can only be determined by the later development, not by the original
>development of the class.  Not all classes need to be reused and a class
>should not be designed for reuse until there is a demonstrated need.

I would change this to "an anticipated need", rather than "a
demonstrated need".  And generally this means that you separate the
classes into base classes which capture the abstraction, and derived
classes which capture the detail.  Then you write the clients such
that they use the base class interface rather than the derived class.
This is a *relatively* cheap procedure.

Quote:
>> >However, given the existence of bounded contexts, there is no such
>> >thing as "pure" or 'abstract' interface with no dependance whatsoever
>> >on implementation.  

>> Of course there is.  

>> class AbstractB
>> {
>>   public:
>>    virtual void X() = 0;
>> };

>> The class AbstractB has utterly no dependency at all upon any
>> potential implementation of X in a derived class.

>Not being knowledgeable in C++ i have to ask - what use does this
>class serve?  I get the feeling that, by your definitions, a perfect
>class would define objects that provided no services - how is it possible
>for an object to provide services without those services being needed
>in and determined by the context where the object lives?

The class Abstract B provides a service X.  Nothing more is known.  

Lets make this a little more real:

class Modem
{
  public:
    virtual void Dial(PhoneNumber) = 0;
    virtual void OffHook() = 0;
    virtual void OnHook() = 0;
    virtual void SendChar(char) = 0;
    virutal char GetChar() = 0;

Quote:
};

Here is an abstract interface for a modem.  None of the functions are
implemented, the interfaces are pure.

I can now write functions which manipulate modems in terms of this
abstract interface.  I can also derive HayesModem from Modem such that
those programs can manipulate HayesModems through the Modem interface.
Thus those programs do not even know that HayesModem exists.

Quote:
>> We can use Structured Analysis and Design to create modules that can
>> be "used".  But, as history has shown, we need something more.  Not
>> only must modules be usable, they must be maintainable.  They must
>> survive their lifecycle.  And this means that we have to design the
>> modules for survivability.  One very important criterion is the
>> management of dependencies between modules.  A module with very few
>> dependencies is more robust than a module with many dependencies.  

>Yes, encapsulation is good, but this does not require that the
>object be designed for reuse.  It simply requires that the object
>be well-defined.

I am not talking simply about encapsulation.  Morever, encapsulation
without a strategy is only marginally useful.  The stragegy requires
that we examine the collaborations of many objects and then attempt to
define interfaces that can be abstracted such that the dependencies
between the collaborators are broken.  *Then* we can encapsulate the
resulting interfaces.

- Show quoted text -

Quote:
>> >>What is
>> >>the goal of OOD?  What benefits are we trying to gain.  

>> >How to design useful objects.  

>> Why objects?  Why not just useful code?

>> >The benefits of encapsulation,

>> What are the benefits of encapsulation, if not the management of
>> dependency?

>> >inheritance, polymorphism,

>Inheritance and polymorphism are where the reuse comes from,
>not from the "management of dependencies between modules."

Inheritance and polymorphism are the tools that allow dependencies to
be managed.  Such management affords reuse and maintainability.

It is quite easy to write code that is rife with inheritance and
polymorphism, and yet is not reusable or maintainable.

--
Robert Martin       | Design Consulting   | Training courses offered:

2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++



Sat, 05 Jul 1997 04:09:08 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Teaching OO

2. Information on teaching OO and Reuse (redux)

3. Information on teaching OO and Reuse (redux)

4. Information on teaching OO and Reuse sought

5. Teaching OO

6. Information on teaching OO and Reuse sought

7. Information on teaching OO and Reuse (redux)

8. Information on teaching OO and Reuse sought

9. Teaching OO using Ruby

10. Teaching OO

11. Teaching OO

12. Information on teaching OO and Reuse (redux)

 

 
Powered by phpBB® Forum Software