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

Object Oriented Software Construction - Bertrand Meyer

DisciplinaProgramação Orientada A Objetos3.995 materiais58.080 seguidores
Pré-visualização50 páginas
to know more about implementations
tions than is conceptually necessary. 
es, overloading and genericity, offer candidate solutions in the effort to bring
ty to the mechanisms just described. Let us study what they can contribute. 
is the ability to attach more than one meaning to a name appearing in a
st common source of overloading is for variable names: in almost all
fferent variables may have the same name if they belong to different modules
ol style of languages, different blocks within a module).
levant to this discussion is routine overloading, also known as operator
which allows several routines to share the same name. This possibility is
s available for arithmetic operators (hence the second name): the same
 b, denotes various forms of addition depending on the types of a and b
le-precision real, double-precision real). But most languages do not treat an
h as "+" as a routine, and reserve it for predefined basic types \u2014 integer, real
 Starting with Algol 68, which allowed overloading the basic operators,
ages have extended the overloading facility beyond language built-ins to
operations and ordinary routines. 
for example, a package may contain several routines with the same name, as
gnatures of these routines are different, where the signature of a routine is
by the number and types of its arguments. (The general notion of signature
the type of the results, if any, but Ada resolves overloading on the basis of
s only.) For example, a package could contain several square functions: 
x: INTEGER): INTEGER is do \u2026 end
x: REAL): REAL is do \u2026 end
x: DOUBLE): DOUBLE is do \u2026 end
x: COMPLEX): COMPLEX is do \u2026 end
 a particular call of the form square (y), the type of y will determine which
 routine you mean. 
A package could similarly declare a number of search functions, all of the form 
has (t: \u201cSOME_TABLE_TYPE\u201d; x: ELEMENT) is do \u2026 end
supporting various table implementations and differing by the actual type used in lieu of
suffices to de
These o
will be useful
What do
is a syntactic
various impl
compiler. Bu
overloading d
has (t, x
you must hav
about the deta
of table t is! T
cases. Withou
Is the po
rule of softw
differences in
is essential to
If the has rou
software into
client (as with
The furt
criterion used
merit. It work
all of differen
would be the
graphics syste
p1 := ne
same c
LE_TYPE\u201d. The type of the first actual argument, in any client\u2019s call to has,
termine which routine is intended. 
bservations suggest a general characterization of routine overloading, which
 when we later want to contrast this facility with genericity:
es routine overloading really bring to our quest for reusability? Not much. It
 facility, relieving developers from having to invent different names for
ementations of an operation and, in essence, placing that burden on the
t this does not solve any of the key issues of reusability. In particular,
oes nothing to address Representation Independence. When you write the call 
e declared t and so (even if information hiding protects you from worrying
ils of each variant of the search algorithm) you must know exactly what kind
he only contribution of overloading is that you can use the same name in all
t overloading each implementation would require a different name, as in
ary_tree (t, x)
h (t, x)
ed (t, x)
ssibility of avoiding different names a benefit after all? Perhaps not. A basic
are construction, object-oriented or not, is the principle of non-deception:
 semantics should be reflected by differences in the text of the software. This
 improve the understandability of software and minimize the risk of errors.
tines are different, giving them the same name may mislead a reader of the
 believing that they are the same. Better force a little more wordiness on the
 the above specific names) and remove any danger of confusion. 
her one looks into this style of overloading, the more limited it appears. The
 to disambiguate calls \u2014 the signature of argument lists \u2014 has no particular
s in the above examples, where the various overloads of square and has are
t signatures, but it is not difficult to think of many cases where the signatures
 same. One of the simplest examples for overloading would seem to be, in a
m, a set of functions used to create new points, for example under the form
w_point (u, v)
Role of overloading
e overloading is a facility for clients. It makes it possible to write the
lient text when using different implementations of a certain concept.
See the correspon
ing definition of g
nericity on page 9
There are two basic ways to specify a new point: through its cartesian coordinates x
and y (the projections on the horizontal axis), and through its polar coordinates \u3c1 and \u3b8
(the distance to the origin, and the angle with the horizontal axis). But if we overload
function new_point we are in trouble, since both versions will have the signature
This ex
The rece
Semantic o
The form of 
The object-o
binding, whic
be called sem
equivalent of
executes your
Dear Ha
rather r
table ma
you hav
kind of 
and tell 
I regret 
and x a 
With my
Your fri
principle of 
common sem
properties wh
orientation, in
Ada offer syn
above. In an o
More on syntactic 
overloading in 
\u201cMultiple creation 
and overloading\u201d, 
page 239 and \u201cO-O 
development and 
page 564.
ING\u201d, 14.4, page 
How remarkably 
concise software 
languages are in 
int (p, q: REAL): POINT
ample and many similar ones show that type signature, the criterion for
g overloaded versions, is irrelevant. But no better one has been proposed.
nt Java language regrettably includes the form of syntactic overloading just
, in particular to provide alternative ways to create objects.
verloading (a preview)
routine overloading described so far may be called syntactic overloading.
riented method will bring a much more interesting technique, dynamic
h addresses the goal of Representation Independence. Dynamic binding may
antic overloading. With this technique, you will be able to write the
 has (t, x), under a suitably adapted syntax, as a request to the machine that
 software. The full meaning of the request is something like this: 
rdware-Software Machine:
look at what t is; I know that it must be a table, but not what table
ntation its original creator chose \u2014 and to be honest about it I\u2019d much
emain in the dark. After all, my job is not table management but
ent banking [or compiling, or computer-aided-design etc.]. The chief
nager here is someone else. So find out for yourself about it and, once
e the answer, look up the proper algorithm for has for that particular
table. Then apply that algorithm to determine whether x appears in t,
me the result. I am eagerly waiting for your answer.
to inform you that, beyond the information that t is a table of some kind
potential element, you will not get any more help from me.
 sincerest wishes,
endly application developer.
syntactic overloading, such semantic overloading is a direct answer to the
n Independence requirement. It still raises the specter of violating the
non-deception; the answer will be to use assertions to characterize the
antics of a routine that has many different variants (for example, the common
ich characterize has under all possible table implementations). 
 semantic overloading, to work properly, requires the full baggage of object
 particular inheritance, it is understandable that non-O-O languages such as
tactic overloading as a partial substitute in spite of the problems mentioned