Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ucsd!hub!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: A principle of Eiffel design [was: Interesting problems to try in Eiffel]
Summary: Discriminate exactly once
Message-ID: <232@eiffel.UUCP>
Date: 19 Jan 90 23:14:31 GMT
References: <1721@novavax.UUCP> <631@enea.se> <228@eiffel.UUCP> <1731@esquire.UUCP>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 62

In <228@eiffel.UUCP> marc@eiffel.UUCP (Jean-Marc Nerson) wrote:
> > The solution achieves one of the major benefits of object-oriented
> >design: limiting the number of explicit choices between a range of
> >possibilities.

In <1731@esquire.UUCP>, yost@esquire.UUCP (David A. Yost) asked:
> Please explain.

The underlying idea is, I believe, one of the major principles of
Eiffel design. The principle may roughly be expressed as follows:

    Whenever a certain software system deals with a set of
    possible cases for a certain property, there should be
    exactly one part of the system which knows about the list
    of choices.

Examples of ``sets of possible cases'' are:

    - The types of external devices in a real-time or process control system.
    - The commands of an editor.
    - The types of input events in a window system.
    - The non-terminals of the grammar in a compiler

etc.

A major plague of traditional programming is the need to write
numerous discrimination instructions (``case... of...'' or
``if.. then... else'') which will select between the available cases.

We cannot hope to remove all knowledge about the set of possible cases
from the system. Clearly, if an editor is to support a certain command
set, *some* part of the editor has to know what commands are available.
(That part is ``closed'' in the sense in which this word is used in 
``Object-Oriented Software Construction'' section 2.3.) Hence
there is AT LEAST ONE component that ``knows''.

In good object-oriented design, there will be AT MOST ONE
such component. Often, this will be an initialization module,
easy to change and not a very ``deep'' component of the architecture.
(A standard technique is to use a table of objects to record
the knowledge about the set of possible choices; each object in the table
is of a different type, a descendant of the same ancestor class.)
Then any other part of the system performing an action
that may have different variants depending
on each case relies on the techniques of genericity, polymorphism and
dynamic binding (with the help of static typing to avoid mistakes)
to achieve implicit rather than explicit discrimination, as in

    command_set.entry(command_code).execute

The major achievement is that full knowledge of the list of cases is
limited to just one module, making evolution and reuse much easier
than if that information was scattered throughout the code.

Many of the examples I know where an Eiffel
solution achieves a real breakthrough - a quantum leap - as
compared to traditional techniques use (among other techniques!)
some variant of this scheme.
   
-- Bertrand Meyer
bertrand@eiffel.com