development paths (was: ask not what your object can do for you)

[Jecel Assumpcao Jr]

On Tue, 29 Aug 2000, Kyle Lahnakoski wrote:
> Jecel Assumpcao Jr wrote:
> > [AOP isn't OO. Or is it?]
> 
> You do seem to defeat your own point.  But maybe you are talking about a
> subtle difference I can not grasp.

I am talking about the following dilema - I want a "menu" object to:

  1) represent everything menu related in the system
  2) represent nothing but menu related things

Of course, objects are never as self contained as this. They delegate
to their "acquaintances" most of their real work, and they inherit from
their superclasses the definition for most of the rest.

AOP and reflection move things like #byteSize and #instanceVariables
from the menu object itself and place them elsewhere. If I consider
these things very unmenulike, then doing this has increased 2 and left
1 alone, making the system even more OO than before.

On the other hand, if I consider these things to be an integral part
of what it is to be a menu inside a computer (I don't think like this,
but know many people who do) then I have reduced 1 (you now have to
look in several places to understand an object) and the system is less
OO than before.

I am thinking out loud about two alternatives, thus "defeating my own
point" as you say.

> > [Scandanavian vs American "schools" of OO]
> 
> These appear to be development techniques, and unrelated to your
> previous points.  Maybe you can help me here and tell me how this ties
> into the rest of your reply.  

You can see how different the tools that were developed for these two
different development styles are, right? Static vs dynamic typing,
explicit compilation vs interpretation/automatic compilation,
separation of applications and development systems vs integrated
world...

> > [Platonic and Aristotelian world models]
> 
> I never thought of it that way before.  But you must admit there is a
> strong correspondence between the emergent abstractions in the
> Aristotelian view and the ideal world in the Platonic view.  This
> bijection between views makes discussing one, or the other, useless to
> solving the dilemma at hand. 

Yes - in theory you will end up with the exact same result no matter
which path you take to get there. But as someone said: "The difference
between practice and theory is that in theory there is no difference
between practice and theory" ;-)

I was just looking at the technical program for this year's OOPSLA
and notice a paper called "An Aristotelian Understanding of
Object-Oriented Programming" by Derek Rayside (University of Waterloo)
and Gerard Campbell (St. Jerome's University). I hope I won't be
contradicted too badly...

   http://oopsla.acm.org/ap/tech/ThurAM.html

> > This is a gross oversimplification, of couse. But the idea is that
> > there are four distinct styles of OO programming. This isn't very
> > obvious if you only look at the end results since they tend to be very
> > similar. It is the roads to get there that are different.
> 
> You do want to consider both the "right" design and the paths taken to
> get there.  I think you are complicating the issue. 

Probably.

> Given a certain
> amount of information, there is a correct design for it.  And we need
> not consider just the formal meaning of information in this last
> sentence.  Information on a domain can be artificially restricted by the
> fact the human programmer can not remember all the details. 

You are ignoring the role of personal taste. Surely if I am a huge APL
fan I will come up with a very different design from a C fan even given
the exact same information? Or do you consider what I call "taste" to
be part of the information that is brought to bear on the problem?

> As new
> information becomes available the "right" design changes.  With this
> characterization of "right" design wrt the available information, we can
> show the development cycle as simply the changes in available
> information on the domain.  I see no problem talking about "right"
> design, and development processes as two perpendicular aspects of
> programming.  

Right - you can consider the iterative (or "spiral") model of
development as a sequence of "mini-waterfalls". So for a tiny piece of
the development process it looks the same no matter what path we haven
chosen to take.

> I think I understand what you were saying now, and you have heard my
> objections.  I am open to the possibility that there could be some
> issues that can not be separated into these two aspects.  If you have,
> please let me know.  

Well, in theory you can do Extreme Programming in C++ and a very formal
development in Smalltalk. In practice, however, different development
paths tend to work better with different development tools and they
also tend to produce different results. That is all I am saying.

Cheers,
-- Jecel