TITLE: controling dependencies

(Newsgroups: comp.lang.c++.moderated)


JASON: JVU@news-e2c.gnn.com (Jason)

> [snip]
> >String class should be asked to write itself to disk.
> 
> >Can't one arbitrarily say that the "disk" object should know how
> >to write a String?


TONG: Kent Tong

> Because this way the disk object would have to be modified
> whenever a new class is introduced that needs to be saved
> to the disk. This is obviously against code reuse.

CLARKE: Allan Clarke <clarke@ses.com>, 9 Aug 96

Lets take a half step back and restate the example. Suppose we have
an object instance that needs to be written to a particular device.
We could put the write capability on the device. This design clearly
suffers; when new object classes are added to the system, the device
class needs to be modified to accommodate the new object classes.

It is equally valid to try to put the write capability on the
object class. This too suffers; when new devices are added to the
system, the object class must be modified. 

Either of these designs are poor due to the dependencies of one
class on another. It would be far better to break this dependency
by using mechanisms like abstract classes and inheritance. For example,
we might choose to create an abstract device/stream class from which
all specific devices derive. Now the object class depends on an
abstract class rather than a concrete class and has some immunity from
new devices being added to the system.

JASON:

> >If you want the string class (or any other class) to have all the
> >responsibility for user interface drawing, and writing to disk,
> >etc, there's an infinite # of possible member functions to add
> >to any class.  When do you know you don't need to add any more
> >and let outside functions work on the class instead?


TONG:

> This is a harder question. [snip]

CLARKE:

I stopped the quotation here since this is where we still agree.
Statements like "strings should draw themselves" always perplex
me. Our job as designers is to build systems that work *AND* have
other desirable properties, like maintainability and flexibility
(all constrained of course by time and/or money).

A string that knew how to draw itself is the mark of either a "quick-
and-dirty" or of a poorly thoughtout design. Why would you pollute a
string abstraction with knowledge of gui display? What about the
case where the same string instance is represented on multiple views,
each with a different display behavior? Do you keep adding methods to
the string class to cover each display vehicle? This design is rapidly
crumbling under stress.

A better design is to have strings free of knowledge of GUI concerns
and use a mediator class between the "view that displays information"
and the string itself. Strings don't know about views. Views don't
know about strings (just mediators). Sounds like we're back on track
in controlling those dependencies.

-- 
:  Allan Clarke  : "All that is necessary for evil to abound is for   :
: clarke@ses.com :       good men to do nothing" -Edmond Burke        :
:    SES, Inc    :             http://www.ses.com/~clarke             :
: Austin, Texas  :           512/328-5544  512/327-6646(fax)          :