Object Oriented Software Construction - Bertrand Meyer
1370 pág.

Object Oriented Software Construction - Bertrand Meyer


DisciplinaProgramação Orientada A Objetos3.942 materiais57.517 seguidores
Pré-visualização50 páginas
it takes the time to
ethodological concerns that lead to the central O-O concepts. Its focus is on
hat it takes to devise satisfactory structures for \u201cin-the-large\u201d system
It ends with a presentation of abstract data types, the mathematical basis for
logy. The mathematics involved is elementary, and less mathematically
ers may content themselves with the basic ideas, but the presentation
theoretical background that you will need for a full understanding of O-O
 issues. 
 the technical core of the book. It presents, one by one, the central technical
f the method: classes; objects and the associated run-time model; memory
issues; genericity and typing; design by contract, assertions, exceptions;
he associated concepts of polymorphism and dynamic binding, and their
 applications. 
discusses methodology, with special emphasis on analysis and design.
ral in-depth case studies, it presents some fundamental design patterns, and
entral questions as how to find the classes, how to use inheritance properly,
design reusable libraries. It starts with a meta-level discussion of the
quirements on methodologists and other advice-givers; it concludes with a
e software process (the lifecycle model) for O-O development and a
 how best to teach the method in both industry and universities.
 explores advanced topics: concurrency, distribution, client-server
and the Internet; persistence, schema evolution and object-oriented
 design of interactive systems with modern (\u201cGUI\u201d) graphical interfaces.
PREFACEviii
Part F is a review of how the ideas can be implemented, or in some cases emulated,
in various languages and environments. This includes in particular a discussion of major
object-oriented languages, focusing on Simula, Smalltalk, Objective-C, C++, Ada 95 and
Java, and an assessment of how to obtain some of the benefits of object orientation in such
non-O-O lang
Part G (
and provides 
As com
library classe
A Book-W
It can be amu
books, somet
any attention,
however, to s
had in mind f
real reader, a
The ans
that the Mode
to avoid the m
mathematical
explicitly. Th
later developm
that reason be
the material a
Because
topics are tig
Book-Wide W
Reader is to i
some stage ar
not want any 
cheating on th
Both th
useful in sub
oriented con
components. 
it possible to 
The CD
convenient w
have been pre
Chapters 33 to 35.
-
uages as Fortran, Cobol, Pascal, C and Ada. 
doing it right) describes an environment which goes beyond these solutions
an integrated set of tools to support the ideas of the book.
plementary reference material, an appendix shows some important reusable
s discussed in the text, providing a model for the design of reusable software. 
ide Web
sing to see authors taking pains to describe recommended paths through their
imes with the help of sophisticated traversal charts \u2014 as if readers ever paid
 and were not smart enough to map their own course. An author is permitted,
ay in what spirit he has scheduled the different chapters, and what path he
or what Umberto Eco calls the Model Reader \u2014 not to be confused with the
lso known as \u201cyou\u201d, made of flesh, blood and tastes.
wer here is the simplest possible one. This book tells a story, and assumes
l Reader will follow that story from beginning to end, being however invited
ore specialized sections marked as \u201cskippable on first reading\u201d and, if not
ly inclined, to ignore a few mathematical developments also labeled
e real reader, of course, may want to discover in advance some of the plot\u2019s
ents, or to confine his attention to just a few subplots; every chapter has for
en made as self-contained as possible, so that you should be able to intake
t the exact dosage which suits you best.
 the story presents a coherent view of software development, its successive
htly intertwined. The margin notes offer a subtext of cross references, a
eb linking the various sections back and forth. My advice to the Model
gnore them on first reading, except as a reassurance that questions which at
e left partially open will be fully closed later on. The real reader, who may
advice, might use the cross references as unofficial guides when he feels like
e prearranged order of topics.
e Model Reader and the real reader should find the cross references mostly
sequent readings, to make sure that they have mastered a certain object-
cept in depth, and understood its connections with the method\u2019s other
Like the hyperlinks of a WWW document, the cross references should make
follow such associations quickly and effectively.
-ROM that accompanies this book and contains all of its text provides a
ay to follow cross references: just click on them. All the cross references
served.
Chapter 36.
Appendix A.
See \u201cAbout the 
accompanying CD
ROM\u201d, page xiv.
PREFACE ix
The notation
In software perhaps even more than elsewhere, thought and language are closely
connected. As we progress through these pages, we will carefully develop a notation for
expressing o
implementati
Here an
author\u201d: as in
other words 
involved in th
This ass
started readin
that as we exp
supporting no
feel that you 
This exp
is in fact sup
company (ISE
the text, and 
method for re
language is an
In addit
support for t
language at a
method: to le
top of the con
from historica
with older fo
course you m
perhaps faire
syntax has be
What counts 
you understan
Most so
language or a
reader in the 
and discuss th
explaining th
resolved. I of
designers had
what alternat
hope, provide
construction, 
bject-oriented concepts at all levels: modeling, analysis, design,
on, maintenance. 
d everywhere else in this book, the pronoun \u201cwe\u201d does not mean \u201cthe
 ordinary language, \u201cwe\u201d means you and I \u2014 the reader and the author. In
I would like you to expect that, as we develop the notation, you will be
e process. 
umption is not really true, of course, since the notation existed before you
g these pages. But it is not completely preposterous either, because I hope
lore the object-oriented method and carefully examine its implications the
tation will dawn on you with a kind of inevitability, so that you will indeed
helped design it. 
lains why although the notation has been around for more than ten years and
ported by several commercial implementations, including one from my
), I have downplayed it as a language. (Its name does appear in one place in
several times in the bibliography.) This book is about the object-oriented
using, analyzing, designing, implementing and maintaining software; the
 important and I hope natural consequence of that method, not an aim in itself. 
ion, the language is straightforward and includes very little else than direct
he method. First-year students using it have commented that it was \u201cno
ll\u201d \u2014 meaning that the notation is in one-to-one correspondence with the
arn one is to learn the other, and there is scant extra linguistic decoration on
cepts. The notation indeed shows few of the peculiarities (often stemming
l circumstances, machine constraints or the requirement to be compatible
rmalisms) that characterize most of today\u2019s programming languages. Of
ay disagree with the choice of keywords (why do rather than begin or
?), or would like to add semicolon terminators after each instruction. (The
en designed so as to make semicolons optional.) But these are side issues.
is the simplicity of the notation and how directly it maps to the concepts. If
d object technology, you almost know it already. 
ftware books take the language for granted, whether it is a programming
 notation for analysis or design. Here the approach is different; involving the
design means that one must not only explain the language but also justify it
e alternatives. Most of the chapters of part C include a \u201cdiscussion\u201d section
e issues encountered during the design of the notation,