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

Object Oriented Software Construction - Bertrand Meyer

DisciplinaProgramação Orientada A Objetos3.895 materiais57.254 seguidores
Pré-visualização50 páginas
is a syntactic facility which does not solve the important issues
, and harms the readability of software texts. 
ity helps, but only deals with the issue of type variation. 
e need: techniques for capturing commonalities within groups of related data
e implementations; and techniques for isolating clients from having to know
ce of supplier variants. 
The first published discussion of reusability in software appears to have been McIlroy\u2019s
1968 Mass-Produced Software Components, mentioned at the beginning of this chapter.
His paper [McIlroy 1976] was presented in 1968 at the first conference on software
advocated the
below th
When w
My thes
the abs
One of t
discussed abo
Rather th
A speci
Biggerstaff a
attention of t
[Jones 1984],
same editors 
[Tracz 1988]
into a useful b
One app
the MIT Pro
reproduced in
actual reusab
common prog
Three \u201c
Modula-2 and
references to
languages of 
of a package 
The mo
it will o
Ada is covered in 
chapter 33; see its 
CAL NOTES\u201d, 
33.9, page 1097.
convened by the NATO Science Affairs Committee. (1976 is the date of the
[Buxton 1976], whose publication was delayed by several years.) McIlroy
 development of an industry of software components. Here is an extract: 
e production today appears in the scale of industrialization somewhere
e more backward construction industries. I think its proper place is
rably higher, and would like to investigate the prospects for mass-
ion techniques in software\u2026
e undertake to write a compiler, we begin by saying \u201cWhat table
ism shall we build ?\u201d. Not \u201cWhat mechanism shall we use?\u201d\u2026
is is that the software industry is weakly founded [in part because of]
ence of a software components subindustry\u2026 Such a components
 could be immensely successful.
he important points argued in the paper was the necessity of module families,
ve as one of the requirements on any comprehensive solution to reuse.
an the word \u201cmodule\u201d, McIlroy\u2019s text used \u201croutine\u201d; in light of this chapter\u2019s
n, this is \u2014 with the hindsight of thirty years of further software engineering
ent \u2014 too restrictive.
al issue of the IEEE Transactions on Software Engineering edited by
nd Perlis [Biggerstaff 1984] was influential in bringing reusability to the
he software engineering community; see in particular, from that issue,
 [Horowitz 1984], [Curry 1984], [Standish 1984] and [Goguen 1984]. The
included all these articles (except the first mentioned) in an expanded
collection [Biggerstaff 1989]. Another collection of articles on reuse is
. More recently Tracz collected a number of his IEEE Computer columns
ook [Tracz 1995] emphasizing the management aspects.
roach to reuse, based on concepts from artificial intelligence, is embodied in
grammer\u2019s Apprentice project; see [Waters 1984] and [Rich 1989],
 the first and second Biggerstaff-Perlis collections respectively. Rather than
le modules, this system uses patterns (called clichés and plans) representing
ram design strategies.
encapsulation languages\u201d were cited in the discussion of packages: Ada,
 CLU. Ada is discussed in a later chapter, whose bibliography section gives
 Modula-2, CLU, as well as Mesa and Alphard, two other encapsulation
the \u201cmodular generation\u201d of the seventies and early eighties. The equivalent
in Alphard was called a form.
st important characteristic of a software components industry is that
ffer families of [modules] for a given job.
An influential project of the nineteen-eighties, the US Department of Defense\u2019s
STARS, emphasized reusability with a special concern for the organizational aspects of
the problem, and using Ada as the language for software components. A number of
contributions on this approach may be found in the proceedings of the 1985 STARS DoD-
Industry conf
The two
however, dow
to keep the s
creator of the
should alway
[Cox 19
A form 
extended it to
of the mechan
language [Ab
in this book. T
(The initials s
The wo
searching is 
which cover t
Two bo
reusability. R
and implem
exert its effo
reuse to appli
[M 1996].
erence [NSIA 1985].
 best-known books on \u201cdesign patterns\u201d are [Gamma 1995] and [Pree 1994].
 1987] is a plea for the distribution of software in source form. That article,
nplays the need for abstraction; as pointed out in this chapter, it is possible
ource form available if needed but use a higher-level form as the default
n for the users of a module. For different reasons, Richard Stallman, the
 League for Programming Freedom, has been arguing that the source form
s be available; see [Stallman 1992].
92] describes the idea of superdistribution.
of overloading was present in Algol 68 [van Wijngaarden 1975]; Ada (which
 routines), C++ and Java, all discussed in later chapters, make extensive use
ity appears in Ada and CLU and in an early version of the Z specification
rial 1980]; in that version the Z syntax is close to the one used for genericity
he LPG language [Bert 1983] was explicitly designed to explore genericity.
tand for Language for Programming Generically.)
rk cited at the beginning of this chapter as the basic reference on table
[Knuth 1973]. Among the many algorithms and data structures textbooks
he question, see [Aho 1974], [Aho 1983] or [M 1978].
oks by the author of the present one explore further the question of
eusable Software [M 1994a], entirely devoted to the topic, provides design
entation principles for building quality libraries, and the complete
of a set of fundamental libraries. Object Success [M 1995] discusses
aspects, especially the areas in which a company interested in reuse should
rts, and areas in which efforts will probably be wasted (such as preaching
cation developers, or rewarding reuse). See also a short article on the topic,
Towards o
defined in th
method for de
This cha
reaching idea
develops the 
A word 
readers might
This would b
common misu
\u201cstructured\u201d i
Only by caref
uses of the bu
5.1 THE 
The crucial q
what criteria s
To obta
The basic t
Three forces 
The three 
forces of 
bject technology
y, reusability and reliability, our principal goals, require a set of conditions
e preceding chapters. To achieve these conditions, we need a systematic
composing systems into modules.
pter presents the basic elements of such a method, based on a simple but far-
: build every module on the basis of some object type. It explains the idea,
rationale for it, and explores some of the immediate consequences.
of warning. Given today\u2019s apparent prominence of object technology, some
 think that the battle has been won and that no further rationale is necessary.
e a mistake: we need to understand the basis for the method, if only to avoid
ses and pitfalls. It is in fact frequent to see the word \u201cobject-oriented\u201d (like
n an earlier era) used as mere veneer over the most conventional techniques.
ully building the case for object technology can we learn to detect improper
zzword, and stay away from common mistakes reviewed later in this chapter.
uestion in our search for proper software architectures is modularization:
hould we use to find the modules of our software?
in the proper answer we must first examine the contending candidates.
are at play when we use software to perform some computations:
Action Object
To execute a software system is to use certain processors to apply certain actions to
certain objects.
The processors are the computation devices, physical or virtual, that