[comp.lang.smalltalk] Request for book review : OOP books

bob@pdn.UUCP (Bob Hickle) (05/26/88)

I have recently received a flyer from Prentice Hall advertising
the following two books on object oriented design.  Has anyone
out there read these books?  If so, how about posting a brief
book review.  Opinions welcome.  Are these books worth the price?

The books:

Object-oriented Software Construction by Bertrand Meyer.
[Date unknown], 534 pages, cloth book.
Price on the flyer is $31.45 (a 15% discount).

    [ This book appears to present o-o concepts and design
      using the Eiffel programming language for its examples.
      It is a long book.  Is quantity = quality here?  Is
      this just an advertisement for Eiffel? ]

Object-oriented Systems Analysis: Modeling The World In Data
by Sally Shlaer and Stephen Mellor.
April 1988, 160 pages, paper book.
Price on the flyer is $19.55 (a 15 % discount).

    [ Sounds like an attempt to describe how to model the
      real world in terms of an information model, which
      is then represented as a set of data relationships. ]

Any info on these books would be appreciated.
-----------------------------------------------------------------------
Bob Hickle				Paradyne Corporation
uunet!pdn!bob				Mail stop LF-207
gatech!uflorida!usfvax2!pdn!bob		8550 Ulmerton Road, PO Box 2826
Phone: (813) 530-2664			Largo, FL  34641

day@grand.UUCP (Dave Yost) (05/28/88)

In article <3274@pdn.UUCP> bob@pdn.UUCP (Bob Hickle) writes:
>Has anyone out there read these books?  If so, how about posting
>a brief book review.
>
>[one of] The books:
>
>Object-oriented Software Construction by Bertrand Meyer.
>May, 1988, 534 pages, cloth book.
>Price on the flyer from Prentice-Hall is
>$31.45 (a 15% discount).
>
>    [ This book appears to present o-o concepts and design
>      using the Eiffel programming language for its examples.
>      It is a long book.  Is quantity = quality here?  Is
>      this just an advertisement for Eiffel? ]

So far, I've read the first 9 chapters, and have peeked
at some later chapters.  This is a very well-written,
readable book, loaded with historical references.  The
author's presentation of his point of view is well-
motivated and well-organized, and he nearly always
presents and refutes interesting objections to his line
of reasoning.  The book starts with an astute survey
of existing software design practices and problems, and
lays out a set of desirable goals.  He then proceeds to
present his version of the principles of OO design and
shows how they meet many of those goals.

To illustrate and advance the discussion, he presents
his Eiffel language and uses it for the examples.
The book could not have been written any other way
because there is no other existing language that
could demonstrate his view of how software should be
constructed.  If this makes the book an advertisement
for Eiffel, then it is advertisement at the very
loftiest, most educational level.

One of the main thrusts of the book and of the Eiffel
language is the goal of producing error-free software.
The language provides for a very interesting
integration of classes and assertions.  The assertions
serve not only to generate optional runtime checking
code, but as self-documentation of the semantics of
classes and their functions and procedures, and they
mesh with inheritance in a very elegant way.

One message of the book comes through loud and clear:
if you want to write error-free software, you want as
much help from the language as possible; the more the
language enforces sanity the better.  This leads to the
obvious (unstated) conclusion that C (or pascal or
whatever) extended with optional higher-level features
(such as classes) is not as powerful a tool for the job
as a well-designed purely higher-level language.  (Is
it a wonder that C wasn't implemented as extensions to
assembler language?  I guess that was back when they
didn't care if anyone else ever used it.)

One amazing tidbit about the book is that the author is
French (though he's been mostly stateside since '83),
yet his writing in English is superb.  I guess he's
good at languages (he also has a Master's degree in the
Russian language.)  He has an M.S. from Stanford and a
Ph.D. from the University of Nancy in France.

My perspective:
I have programmed in C for nine years, and as time goes
by I have become increasingly impatient with the grunge
level of C.  My quest for a higher level language has
led me to Icon, C++, and Eiffel, which I hope to try
soon.

 --dave yost

day@grand.UUCP (Dave Yost) (05/29/88)

In article <412@grand.UUCP> day@grand.UUCP (I) Yost) wrote:
>So far, I've read the first 9 chapters, and have peeked
>at some later chapters.  This is a very well-written,
>readable book, loaded with historical references.  The
>author's presentation of his point of view is well-
>motivated and well-organized, and he nearly always
>presents and refutes interesting objections to his line
>of reasoning.  The book starts with an astute survey
>of existing software design practices and problems, and
>lays out a set of desirable goals.  He then proceeds to
>present his version of the principles of OO design and
>shows how they meet many of those goals.
> [etc.]

I forgot to tell you where I know for sure that you
can get a copy of this book that doesn't seem to be
in stores yet.

The book is
    Object-oriented Software Construction
    by Bertrand Meyer
    Prentice Hall
    International Series in Computer Science
    ISBN 0-13-629049-3 hardcover
    ISBN 0-13-629031-0 paperback (apparently
    won't be available in the US)

His company will ship it to you if you charge
it to your MC-VISA number or pay for it C.O.D.
It's $36.00.

    Interactive Software Engineering
    805-685-1006
    270 Storke Road, Suite 7
    Goleta, CA  93117

 --dave yost

robert@pvab.UUCP (Robert Claeson) (05/31/88)

In article <412@grand.UUCP>, day@grand.UUCP (Dave Yost) writes:

> One of the main thrusts of the book and of the Eiffel
> language is the goal of producing error-free software.

> My quest for a higher level language has
> led me to Icon, C++, and Eiffel, which I hope to try
> soon.

Can I buy Eiffel? From who? Or are there other, alternative
implementations?

day@grand.UUCP (Dave Yost) (06/02/88)

In article <239@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes:
>
>Can I buy Eiffel? From whom? Or are there other implementations?

Bertrand Meyer's company sells an Eiffel compiler with
class library and a bunch of tools.

    Interactive Software Engineering
    805-685-1006
    270 Storke Road, Suite 7
    Goleta, CA  93117

The class library is especially useful because it has
a lot of container classes in it, like tree, array,
linked list, two-way linked list, stack, etc.  Eiffel
has genericity, aka parameterized types, so you can put
anything you want in those containers.  For example,
    pnt: TREE[POINT],
    poly: LINKED_LIST[POLYGON]
uses only one one copy of the LINKED_LIST container
code, even though LINKED_LIST is inherited by the TREE
class.

Three of these tools are really interesting:
   flat    translate a class definition into one in
	   which all the inherited features are merged
	   into the class itself so the reader doesn't
	   have to poke around in the inheritance
	   structure to see what's what.
   short   translate a class definition into a short
	   form to serve as the documentation on the
	   class interface.
	   A -t flag makes troff output.
   es      build a program from a specified collection
	   of classes with various compile-time options.

Class definitions have a 1-to-1 correspondence with
files.  There are no header files to keep in sync,
and there is no separate list of dependencies (as in
Makefiles) to keep in sync (you don't use make, except
perhaps at some outer level).  The class definition
file itself serves as the sole repository for
information about a class.  The program building tool,
es, understands enough about Eiffel to determine class
dependencies, and recompiles classes as necessary if
you change something.  For instance, if there is no
change to the exported interface in class A, then
client class B will not be recompiled, and if only some
code inside a routine of class A is changed, neither B
nor heir class C will be recompiled.

The compiler generates C, the portable low-level
language of our day.

I haven't tried this stuff yet, I've just seen a demo
and read about it.

 --dave