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

Object Oriented Software Construction - Bertrand Meyer


DisciplinaProgramação Orientada A Objetos3.887 materiais57.123 seguidores
Pré-visualização50 páginas
principle
All services offered by a module should be available through a uniform
notatio
storage
guages satisfy this principle. An older one that did was Algol W, where both
all and the access to a field were written a (x). Object-oriented languages
 Uniform Access, as did the first of them, Simula 67, whose notation is x l f
 The notation developed in part C will retain this convention.
losed principle 
irement that any modular decomposition technique must satisfy is the Open-
ple:
tradiction between the two terms is only apparent as they correspond to goals
nature: 
le is said to be open if it is still available for extension. For example, it should
ble to expand its set of operations or add fields to its data structures.
le is said to be closed if it is available for use by other modules. This assumes
module has been given a well-defined, stable description (its interface in the
 information hiding). At the implementation level, closure for a module also
that you may compile it, perhaps store it in a library, and make it available
rs (its clients) to use. In the case of a design or specification module, closing
e simply means having it approved by management, adding it to the project\u2019s
repository of accepted software items (often called the project baseline), and
ng its interface for the benefit of other module authors. 
d for modules to be closed, and the need for them to remain open, arise for
ons. Openness is a natural concern for software developers, as they know that
possible to foresee all the elements \u2014 data, operations \u2014 that a module will
etime; so they will wish to retain as much flexibility as possible for future
extensions. But it is just as necessary to close modules, especially from a
er\u2019s viewpoint: in a system comprising many modules, most will depend on
a user interface module may depend on a parsing module (for parsing
ts) and on a graphics module, the parsing module itself may depend on a
n, which does not betray whether they are implemented through
 or through computation.
Open-Closed principle
Modules should be both open and closed.
MODULARITY §3.358
lexical analysis module, and so on. If we never closed a module until we were sure it
includes all the needed features, no multi-module software would ever reach completion:
every developer would always be waiting for the completion of someone else\u2019s job. 
With traditional techniques, the two goals are incompatible. Either you keep a
module open,
trigger a pain
original modu
The two
closed modu
modules B, C
Later on
others \u2014 whi
With no
N1 \u2022 You m
function
N2 \u2022 You ma
to A' in
With th
d 
B
F
G
B
 and others cannot use it yet; or you close it, and any change or extension can
ful chain reaction of changes in many other modules, which relied on the
le directly or indirectly. 
 figures below illustrate a typical situation where the needs for open and
les are hard to reconcile. In the first figure, module A is used by client
, D, which may themselves have their own clients (E, F, \u2026).
, however, the situation is disrupted by the arrival of new clients \u2014 B' and
ch need an extended or adapted version of A, which we may call A': 
n-O-O methods, there seem to be only two solutions, equally unsatisfactory:
ay adapt module A so that it will offer the extended or modified
ality (A' ) required by the new clients. 
y also decide to leave A as it is, make a copy, change the module\u2019s name
 the copy, and perform all the necessary adaptations on the new module.
is technique
 A' retains no further connection to A.
A module an
its clientsA C E
D
Client of
Old and new 
clients
A'
IH
A C E
D
§3.3 FIVE PRINCIPLES 59
The potential for disaster with solution N1 is obvious. A may have been around for
a long time and have many clients such as B, C and D. The adaptations needed to satisfy
the new clients\u2019 requirements may invalidate the assumptions on the basis of which the
old ones used A; if so the change to A may start a dramatic series of changes in clients,
clients of cli
suddenly, ent
off ages ago g
documentatio
Sisyphus synd
of the hill, on
problems cau
On the s
does not requ
figure). But in
day of recko
requests and a
original modu
In many
available func
a huge config
use of comple
first concern 
Configur
which m
But how
and everythin
clients, and a
particularly e
The deta
the basic idea
define a new 
We will write
class A'
A
feature
f is
g i
\u2026
u i
\u2026
end
Exercise E3.6, page 
66, asks you to dis-
cuss how much need 
will remain for con-
figuration manage-
ment in an O-O 
context.
ents and so on. For the project manager, this is a nightmare come true:
ire parts of the software that were supposed to have been finished and sealed
et reopened, triggering a new cycle of development, testing, debugging and
n. If many a software project manager has the impression of living the
rome \u2014 the impression of being sentenced forever to carry a rock to the top
ly to see it roll back down each time \u2014 it is for a large part because of the
sed by this need to reopen previously closed modules. 
urface, solution N2 seems better: it avoids the Sisyphus syndrome since it
ire modifying any existing software (anything in the top half of the last
 fact this solution may be even more catastrophic since it only postpones the
ning. If you extrapolate its effects to many modules, many modification
 long period, the consequences are appalling: an explosion of variants of the
les, many of them very similar to each other although never quite identical.
 organizations, this abundance of modules, not matched by abundance of
tionality (many of the apparent variants being in fact quasi-clones), creates
uration management problem, which people attempt to address through the
x tools. Useful as these tools may be, they offer a cure in an area where the
should be prevention. Better avoid redundancy than manage it.
ation management will remain useful, of course, if only to find the modules
ust be reopened after a change, and to avoid unneeded module recompilations.
 can we have modules that are both open and closed? How can we keep A
g in the top part of the figure unchanged, while providing A' to the bottom
voiding duplication of software? The object-oriented method will offer a
legant contribution thanks to inheritance. 
iled study of inheritance appears in later chapters, but here is a preview of
. To get us out of the change or redo dilemma, inheritance will allow us to
module A' in terms of an existing module A by stating the differences only.
 A' as 
 inherit
redefine f, g, \u2026 end
 \u2026
s \u2026
s \u2026
MODULARITY §3.360
where the feature clause contains both the definition of the new features specific to A',
such as u, and the redefinition of those features (such as f, g, \u2026) whose form in A' is
different from the one they had in A. 
The pictorial representation for inheritance will use an arrow from the heir (the new
class, here A'
Thanks 
to software d
One wa
techniques is
slipshod appr
into computer
seem bad but
able to addres
Spurred by a 
the original to
pollute the so
after a few r
resembling a 
tastelessness o
the presence 
The org
affecting the 
A word
In particular
\u2022 If you h
the need
w 
F
G
B
) to the parent (here A): 
to inheritance, O-O developers can adopt a much more incremental approach
evelopment than used to be possible with earlier methods. 
y to describe the open-closed principle and the consequent object-oriented
 to think of them as a organized hacking. \u201cHacking\u201d is understood here as a
oach to building and modifying code (not in the more recent sense of breaking
 networks, which, organized or not, no one should condone). The hacker may
 often his heart is pure. He sees a useful piece of software, which is almost
s the needs