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

Object Oriented Software Construction - Bertrand Meyer

DisciplinaProgramação Orientada A Objetos3.482 materiais53.222 seguidores
Pré-visualização50 páginas
a certain element
 in a table t of similar elements. The problem has many variants, depending on
ent types, the data structure representation for t, the choice of searching
s are you or your colleagues will indeed have tackled this problem one or
ut what is truly remarkable is that \u2014 if you are like others in the profession
am fragment handling the search operation will have been written at the
able level of abstraction: by writing code in some programming language,
lling existing routines. 
bserver from outside our field, however, table searching would seem an
t for widely available reusable components. It is one of the most researched
puting science, the subject of hundreds of articles, and many books starting
 of Knuth\u2019s famous treatise. The undergraduate curriculum of all computing
tments covers the most important algorithms and data structures. Certainly
ous topic. In addition:
dly possible, as noted, to write a useful software system which does not
one or (usually) several cases of table searching. The investment needed to
 reusable modules is not hard to justify. 
be seen in more detail below, most searching algorithms follow a common
 providing what would seem to be an ideal basis for a reusable solution. 
euse not more common? 
 the serious impediments to reuse are technical; removing them will be the
 following sections of this chapter (and of much of the rest of this book). But
e are also some organizational, economical and political obstacles. 
any times over the past six months did you, or people working for you,
ome program fragment for table searching?
See bibliographic
references on
page 99.
The NIH syndrome 
An often quoted psychological obstacle to reuse is the famous Not Invented Here (\u201cNIH\u201d)
syndrome. Software developers, it is said, are individualists, who prefer to redo everything
by themselves rather than rely on someone else\u2019s work. 
This co
experience. S
good, well-pu
such as the L
language or a
result is clear
reuse them. W
the tools men
default to one
reverse of NI
reusable solu
innovation, b
parser genera
developers\u2019 u
may fear that
over which th
attempts at re
to reuse at all
of good quali
What th
important her
of-a-kind solu
zero: there is
software to ac
however sma
and other ben
reusers that th
This exp
reusers (t
the heat o
to ensure
See [M 1995].
ntention (commonly heard in managerial circles) is not borne out by
oftware developers do not like useless work more than anyone else. When a
blicized and easily accessible reusable solution is available, it gets reused. 
r the typical case of lexical and syntactic analysis. Using parser generators
ex-Yacc combination, it is much easier to produce a parser for a command
 simple programming language than if you must program it from scratch. The
: where such tools are available, competent software developers routinely
riting your own tailor-made parser still makes sense in some cases, since
tioned have their limitations. But the developers\u2019 reaction is usually to go by
 of these tools; it is when you want to use a solution not based on the reusable
that you have to argue for it. This may in fact cause a new syndrome, the
H, which we may call HIN (Habit Inhibiting Novelty): a useful but limited
tion, so entrenched that it narrows the developers\u2019 outlook and stifles
ecomes counter-productive. Try to convince some Unix developers to use a
tor other than Yacc, and you may encounter HIN first-hand.
ing which may externally look like NIH does exist, but often it is simply the
nderstandably cautious reaction to new and unknown components. They
 bugs or other problems will be more difficult to correct than with a solution
ey have full control. Often such fears are justified by unfortunate earlier
using components, especially if they followed from a management mandate
 costs, not accompanied by proper quality checks. If the new components are
ty and provide a real service, fears will soon disappear. 
is means for the producer of reusable components is that quality is even more
e than for more ordinary forms of software. If the cost of a non-reusable, one-
tion is N, the cost R of a solution relying on reusable components is never
 a learning cost, at least the first time; developers may have to bend their
commodate the components; and they must write some interfacing software,
ll, to call them. So even if the reusability savings
efits of reuse are potentially great, you must also convince the candidate
e reusable solution\u2019s quality is good enough to justify relinquishing control.
lains why it is a mistake to target a company\u2019s reusability policy to the potential
he consumers, that is to say the application developers). Instead you should put
n the producers, including people in charge of acquiring external components,
 the quality and usefulness of their offering. Preaching reuse to application
developers, as some companies do by way of reusability policy, is futile: because
application developers are ultimately judged by how effectively they produce their
applications, they should and will reuse not because you tell them to but because you have
done a good enough job with the reusable components (developed or acquired) that it will
be profitable for their applications to rely on these components.
The econom
A potential 
focusing on s
agency to pa
part of a Req
taxpayers or 
crucial effort
On clos
for reusabilit
including in t
reusable, and
criteria. Then
task and be p
Software c
Even if custo
remains on th
constant temp
getting the ne
widely applic
I once h
object techno
that, although
own company
90% of the co
the figure to 
greet with en
The com
at all possible
a software ho
company tha
consultants\u2019 s
ics of procurement 
obstacle to reuse comes from the procurement policy of many large
and government organizations, which tends to impede reusability efforts by
hort-term costs. US regulations, for example, make it hard for a government
y a contractor for work that was not explicitly commissioned (normally as
uest For Proposals). Such rules come from a legitimate concern to protect
shareholders, but can also discourage software builders from applying the
 of generalization to transform good software into reusable components. 
er examination this obstacle does not look so insurmountable. As the concern
y spreads, there is nothing to prevent the commissioning agency from
he RFP itself the requirement that the solution must be general-purpose and
 the description of how candidate solutions will be evaluated against these
 the software developers can devote the proper attention to the generalization
aid for it. 
ompanies and their strategies 
mers play their part in removing obstacles to reuse, a potential problem
e side of the contractors themselves. For a software company, there is a
tation to provide solutions that are purposely not reusable, for fear of not
xt job from the customer \u2014 because if the result of the current job is too
able the customer may not need a next job! 
eard a remarkably candid exposé of this view after giving a talk on reuse and
logy. A high-level executive from a major software house came to tell me
 intellectually he admired the ideas, he would never implement them in his
, because that would be killing the goose that laid the golden egg: more than
mpany\u2019s business derived from renting manpower \u2014 providing analysts and
 on assignment to customers \u2014 and the management\u2019s objective was to bring
100%. With such an outlook on software engineering, one is not likely to
thusiasm the prospect of widely available libraries of reusable components. 
ment was notable for its frankness, but it triggered