Re: Inheritance versus Generics

[mfeldman@seas.gwu.edu (Michael Feldman)]

A Few "Sound Bites" on Object-Oriented Programming
Michael B. Feldman
The George Washington University

-------------------------------------------------------------

"My guess is that object-oriented programming will be in the
1980s what structured programming was in the 1970s.
Everyone will be in favor of it. Every manufacturer will
promote his products as supporting it. Every manager will
pay lip service to it. Every programmer will practice it
(differently). And no one will know just what it is."

Tim Rentsch 1982 (one of the original Xerox Smalltalkers)
(as quoted by Booch)

-------------------------------------------------------------

"Everything is an object these days; if it doesn't have
o-b-j-e-c-t in the name, it won't sell...OOT is so
radically different that we must break and reset
programmers' coding hands before they can write
object-oriented instead of procedural programs. This is
much worse than the structured programming hoopla of the
1970s...If we convert one Cobol programmer per minute to
Smalltalk, we should have a revolution by the time Capt.
Kirk and the USS Enterprise return from Vulca on impulse
power."

Ted Lewis, "The Dark Side of Objects", IEEE Computer, Dec.
1994.


-------------------------------------------------------------
Composition vs. Classification

(paraphrasing here)

Objects gather both data structures and program structures.

Classification: objects are organized in a hierarchy of
classes. General classes contain features common to many
subclasses, and specalized subclasses implement only
behaviors that are common to a subset of the parent class's
objects.

Composition: objects are made of different parts, and that
the same parts can be used to make a variety of
higher-level objects. Each object is designed as an
assembly of lower-level components. There is no need to
know how a component is made in order to use it.

A set of parts that form an object constitutes an
abstraction layer. This is what is generally used in
engineering, and has been especially successful in the
electronic industry.

(quoting directly here)

"Why do so many people believe that classification is the
only 'true' object orientation? Perhaps because OOL
designers place a heavy emphasis on inheritance, which is
clearly necessary only to classification."

J-P Rosen, "What Orientation Should Ada Objects Take?"
Communications of the ACM,  Nov. 1992


-------------------------------------------------------------

"There is a very real tension between inheritance and
encapsulation. To a large degree, the use of inheritance
exposes some of the secrets of an inherited class.
Practically, this means that to understand the meaning of a
particular class, you must often study all of its
superclasses, sometimes including their inside views."

Grady Booch, Object-Oriented Design with Applications,
Benjamin Cummings, 1991.

-------------------------------------------------------------


"OOT has a nasty 'fragile base class problem,' which means
that once a program is designed and implemented as a class
hierarchy, it is maximally coupled. Changing one interface
specification brings the whole house of cards tumbling
down. We were warned against this in 1975 (minimize
coupling, maximize cohesion). Coupling is a serious
maintenance nightmare that bit Mentor Graphics (Falcon
Framework) in the bottom line. How many other software
companies are headed for OOT malaise?"

Lewis, op. cit.

-------------------------------------------------------------

"[I]nheritance is often used not for classification, but
just to grab pieces of code. . .makes a class PARROT
inherit from the class HUMAN-BEING because it needs the
property CAN-SPEAK. This kind of misuse of the inheritance
mechanism, especially when multiple inheritance is
available, is extremely tempting to the programmer who just
wants to 'reuse' existing code, while actually introducing
a terrible mess in the dependencies between objects.

...

"In the slums, people build houses by reusing old items
such as pieces of wood and tires, and adjusting them to
their needs. This kind of reuse is often extremely clever,
and if you absoutely need a shelter rapidly, it is
certainly an efficient method. But will the house withstand
a storm? This is certainly not industrial reuse, which is
building houses from well-engineered, standard
prefabricated components.

...

"Ada object orientation will still not just follow
classification, because classification does not answer
properly a number of requirements for Ada applications. In
general, classification will favor ease of design and
rapidly varying specifications such as those encountered
when prototyping software, while composition will better
match the needs of secure, long-lasting systems, requiring
various implementations of the same abstract behavior."

J-P Rosen, op. cit.

-------------------------------------------------------------


"-- Most past progress in software productivity has come
from eliminating non-inherent difficulties such as awkward
machine languages and slow batch turnaround.

"-- There are not a lot more of these easy pickings.

"-- Radical progress is going to have to come from
attacking the essential difficulties of fashioning complex
conceptual constructs.

"The most obvious way to do this recognizes that programs
are made up of conceptual chunks much larger than the
individual high-level language statement -- subroutines, or
modules, or classes. If we can limit design and building so
that we only do the putting together and parameterization
of such chunks from prebuilt collections, we have radically
raised the conceptual level, and eliminated the vast
amounts of work and the copious opportunities for error
that dwell at the individual statement level.

"Parnas's information-hiding definition of modules is the
first published step in that crucially important research
program, and it is an intellectlual ancestor of
object-oriented programming He defined a module as a
software entity with its own data model and its own set of
operations. Its data can only be accessed via one of its
proper operations.

"The second step was a contribution of several thinkers:
the upgrading of the Parnas module into an abstract data
type, from which many objects could be derived. The
abstract data type provides a uniform way of thinking about
and specifying module interfaces, and an access discipline
that is easy to enforce.

"The third step, object-oriented programming, introduces
the powerful concept of inheritance, whereby classes (data
types) take as defaults specified attributes of their
ancestors in the class hierarchy. Most of what we hope to
gain from object-oriented programming derives in fact from
the first step, module encapsulation, plus the idea of
prebuilt libraries or modules or classes that are designed
and tested for reuse."

Fred Brooks, "The Mythical Man-Month after 20 Years", IEEE
Computer, Sept. 1995.

-------------------------------------------------------------

"Unfortunately for the information technology industry, many
object technology (OT) gurus are still touting the role of
inheritance and subclassing in building reusable business
objects. One well-designed parent, they say, such as a
Customer object, allows developers to effortlessly spawn
dozens of reusable kin. These theories of inheritance sound
pretty good-until you try applying them to building an
industrial -strength application .

"We have spent more than 150 work-years tackling this issue
and many others related to building commercial
object-oriented systems. The verdict on inheritance and
reuse? Uncontrolled and unplanned subclassing results in
code as fragile and hard to maintain as the COBOL programs
we're replacing. Moreover, subclassing often is
counterproductive. Inheritance, by its nature, means
changing the objects designed to be reused, which will
cancel out any benefits of reuse because each new
subclassed object then requires testing, the biggest drag
on rapid development. Our internal studies show that as
much as 60% of the total implementation effort for a
client/server system is spent on testing.

"The best approach is to treat inheritance as a power tool
for churning out objects when appropriate. Inheritance can
give you a boost in programmer productivity, but it won't
make possible the high degree of reuse that delivers the
vital combinition of speed, agility, and power that today's
business systems need.

"That's the crucial equation for making information
technology work: speed + agility + power. By speed, we mean
the overall productivity gains from building applications
from a store of reusable objects. Power means using the
computer to do things that couldn't be done
before-integrating hypertext, graphics, video, and
Integrated Performance Support, which transmit more
information in new ways to knowledge workers. We use the
term "agility" because it conveys much more than
"flexibility," a feature of object technology comnioiily
associated with ease of maintenance. While flexibility-the
system's ability to be adapted to new or changing
specs-remains all important goal for software, agility
refers to the organization as a whole and its ability to
change processes and strategies with the nimbleness of a
small company.

"To build these types of solutions, look to encapsulation.
Encapsulation provides for more useful reuse than
inheritance because it reduces testing, not just
programming. Encapsulated objects project abstract business
traits that make them valuable (and reusable!), rather-
than inheriting and propagating inflexible, un-reusable
code. Moreover, this approach to reuse adds for more value
than inheritance does to object-oriented design because it
delivers the agile systems organizations need to support
continuous reengineering and capitalize on its
benefits-accelerating new services and products to market,
increasing responsiveness to customers, and supporting new
processes and global operations."

Jim Adamczyk and Tom Moldauer (Andersen Consulting) 
Object Magazine, Sept. 1995