Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!wuarchive!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Eiffel as a design language ?
Message-ID: <1050@tetrauk.UUCP>
Date: 10 Dec 90 10:31:24 GMT
References: <1037@tetrauk.UUCP> <4106@tantalum.UUCP> <1045@tetrauk.UUCP> <4212@tantalum.UUCP>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 63

In a recent article I wrote:

>>... in my work the cleanest solution
>>has often only come after several iterations and re-thinks, and in several
>>cases what I've ended up doing is a lot different from what I expected to do
>>when I started.  Much lateral thinking is called for to get it right.

To which Tom Meyer commented:

>I certainly can see that. OOP is rather different is style and feel to the
>other paradigms and it takes getting used to. There is a raging debate right
>now about how to do object oriented design, capture the objects, etc.

On this topic, I would be interested to hear the opinions of Eiffel users on
it's capabilities as a DESIGN language.  The whole issue of how to get object
oriented design right is far from resolved, but it's already clear that it's a
much more iterative process than "conventional" (what ever that means!)
methods.

One of the reasons I'm using Eiffel in my current project is that I find I can
use it to design as I go.  The style, as well as the simplicity of syntax,
means that I can sketch classes in Eiffel, often leaving them incomplete until
I've clarified other details which they depend on.  If I were using say C++
(which is probably the only other practical alternative in my situation), I
think I would have to represent the class design in some form which made the
design itself clear, and then transfer it into code.

Because I'm using a single language to do the design and implementation, I find
that I can easily change the details when I discover that what looked right at
an early stage turns out not to make such good sense once I get down to the
nitty-gritty.  I don't have the problem of going back to what I wrote for the
design and changing it because what I've coded isn't what I thought I was going
to do.  The Eiffel code IS the design of the class.

I don't in fact subscribe to the view that software design and coding are
separable activities - the idea that software coding is somehow "manufacturing"
a software product according to a design.  Software manufacturing is copying
disks!  Designing and coding are all design in progressively greater detail.  A
programmer is a designer;  if he's not, he's in the wrong job.

Of course I'm not saying that the Eiffel code embodies the overall structural
design of a complete system;  you still need something else at a high-level,
but this can generally stop at the block-diagram level of detail.  It's at the
individual class level that I find Eiffel is sufficient in itself.

It is still marginally possible that for technical and/or political reasons our
final product could end up being implemented in C++ or even C (I personally
hope this doesn't have to happen).  However, I will use Eiffel to produce at
least a complete working prototype, and I think I would still continue to use
it as a design language even if I had to do an actual implementation in
something else.

Do other Eiffel users find it valuable as a design aid, or do I just have an
idiosyncratic way of doing things?  If you use it the way I do, what changes
would you make to increase its power as a DESIGN tool?

Just interested!

-- 
Rick Jones
Tetra Ltd.  Maidenhead, 	Was it something important?  Maybe not
Berks, UK			What was it you wanted?  Tell me again I forgot
rick@tetrauk.uucp					-- Bob Dylan