development (was: delegation)

[Jecel Assumpcao Jr]

On Wed, 22 Nov 2000, Bharat Bedia wrote:
> Everybody carries out some element of analysis. Some people call it 
> thinking others call it UML ;-) However, you can "analyse" until the 
> project manager screams at you then you must develop and code. I was 
> hoping to hear about various strategies and modelling techniques 
> people use to :
> a. model the problem domain, and
> b. convert the model into an application 

I like the "extreme programming" development style created by Smalltalk
programmers (http://xprogramming.com/) where you try to balance the
analysis and exploratory aspects of software creation.

They like to use physical cards to help think about how to model the
problem domain.

> (This doesn't have to be in Self. Perhaps someone can point me to a 
> notation for describing prototypical systems - analogous to UML for 
> OO systems?)

I would say that the best notation for the static structure of programs
are the "outliners" themselves. The only problem with this is that they
tend to take up a lot of screen space, so it is hard to see more than a
few at one time. And you want to "sprout" the object references when
looking at an applications with lots of objects.

What attracted many people to Self, even when the language didn't exist
except on paper, was that it was a simple way to see how objects are
related.

There is currently no way to see the dynamic structure (the patterns of
message sends) except to actually run the application step by step in
the debugger. This debugger is the best I have ever seen anywhere
(everything you need is just a click away without a bunch of menus),
but it is too low level and doesn't help in the design phase.

> So for example in the real world, things change and perhaps even in 
> the evolutionary exploratory Self environment, you may get 
> brittleness in the "older" parts of the application. Part of the 
> analysis is to try and perceive the potential for change and so 
> design in the flexibility. I was wondering what techniques people had 
> used to pre-empt these issues (eg. inflexibility) in the prototypical 
> world? 

One of the best things about Self is how you can point to a slot and
move it to another object, radically changing the "inheritance graph"
in less than a second. This makes aggressive refactoring (one of the
basic ideas of extreme programming) a pleasant experience.

A problem with Self is that, now that we no longer really have privacy
declarations, it is very tempting to be lazy and break the
encapsulation of objects. If some object has a reference to a scheduler
object "s", it is too easy to write:

      s tasks addLast: s tasks removeFirst

instead of creating some method so we could write:

      s rescheduleFirst

The first is obviously much more brittle than the second, since it
"hardwires" the fact that schedulers have a tasks slot that point to
list objects. In Smalltalk or C++ I would have to go through the
trouble of creating an accessor method for "tasks" if I want other
objects to see the list, and that might make me pause and think and
write "recheduleFirst" instead. In Self all slots automatically have
accessor methods.

-- Jecel