Re: [long] Inheritance, multipe-inheritance, & coupling
Re: [long] Inheritance, multipe-inheritance, & coupling
- Subject: Re: [long] Inheritance, multipe-inheritance, & coupling
- From: "Erik M. Buck" <email@hidden>
- Date: Sun, 26 Sep 2004 22:42:29 -0400
Inheritance, multiple inheritance, & coupling
The goal of object-oriented programming is to maximize programmer
productivity by simplifying software development and reducing lifetime
software maintenance costs. The principal technique used to achieve the
goal is object reuse. An object that is reused saves the programmer
time because the object would otherwise need to be re-implemented.
Object oriented programming is a packaging technology designed to
promote reuse of software.
One goal of object oriented design including inheritance hierarchies is
to solve problems in reusable ways or take advantage of reuse
opportunities. The same strategies that are commonly applied to design
of individual objects are applied to larger object-oriented design
_patterns_ as well. In fact, patterns that involve many objects benefit
even more from good object-oriented design than simpler systems. One
reason that patterns exist is to help make sure that productivity
gained from reusing the patterns exceeds the productivity gained from
reusing individual objects. The sum is greater than the parts. Design
patterns raise the bar so that multiple interrelated objects of
different classes can be successfully reused together.
So how is reuse maximized ? There are lots of techniques, but the
number one _enemy_ of reuse is coupling.
As a general design goal, coupling between objects should be minimized.
Coupling refers to dependencies between objects. Whenever such
dependencies exist, they reduce opportunities for reusing the objects
independently. Coupling also applies to subsystems within large systems
of objects. It’s important to look for designs that avoid coupling
whenever possible. All of the Cocoa design patterns exist in part to
limit or avoid coupling. For example, the Model-View-Controller (MVC)
pattern is used throughout Cocoa to organize subsystems of classes and
is applied to the design of entire applications. The primary intent of
the MVC pattern is to partition a complex system of objects into three
major subsystems and minimize coupling between the subsystems.
To look at it another way, it is important to use designs that
accommodate changes through the life cycle of a software system.
Designs that are too inflexible ultimately restrict opportunities for
reuse. In the worst case, no reuse occurs because it is easier to
redesign and re-implement a system than it is to make changes within an
existing rigid design.
One way to design for change is to limit coupling between objects. If
there are few dependencies between objects there is a good chance that
drastic changes can be made to one object without affecting the others.
It’s also possible to anticipate certain types of changes and
accommodate them in a design. For example, Delegates provide a
mechanism for one object to modify and control the behavior of another
object without introducing coupling between them. Cocoa contains many
objects controlled by delegates that were not even conceived when the
Cocoa objects themselves were designed. All of the Cocoa design
patterns exist in part to accommodate change. That’s just one of the
reasons that Cocoa is so flexible.
It can’t be said enough times that coupling is the enemy. It is ironic
that inheritance is simultaneously one of the most powerful tools in
object-oriented programming and one of the leading causes of coupling.
In fact, there is no tighter coupling than the relationship between a
class and its inherited super-classes. Cocoa is designed to reduce the
need to use inheritance. The general rule is that when there is a
choice between composition and inheritance, use composition.
Having said all that, sometimes there is no substitute for inheritance
and it is an essential and valuable tool. Just realize that it is only
one of many available tools and it should not be the first choice every
time.
Multiple inheritance has the potential to exponentially increase the
coupling between objects in a design. I won't say that there is never
a time to use multiple inheritance. However, whenever someone wants to
use multiple inheritance in a design, I am immediately suspicious. In
my experience, almost any amount of redesign is warranted to avoid the
use of multiple inheritance, and in almost every case there are great
alternatives including first and foremost patterns like composition,
delegates, clusters, message forwarding, etc.
Note: In C++, inheritance of pure virtual abstract member functions is
approximately equivalent to Java interfaces or Objective-C protocols
and is not considered to necessarily increase coupling. Multiple
inheritance from multiple deep hierarchies of non-abstract lasses
should be avoided.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden