🚀 go-pugleaf

Robert C. Martin (rmartin@oma.com) wrote:
:...
: Class proliferation is a real problem.  And it is often novices that
: have to face it first.  However, the problem is not simply the number
: of classes that the novice produces, but the way in which the novice
: produces them.  The novice will say:  "Oh gee, I could use a class for
: this, and that, and the other, and -- wow -- I could use a class for
: all kinds of things."  The result is a whole bunch of classes
: conglomerated together into a morrass of "Gee Whizes". 

A few classes may or may not be what is required.  The real question is
what does the vocabulary of the domain require?  Whether or not the
required number of domain vocabulary classes results in a "morass" depends
on how how well the developer uses an architecture to pull things
together. 

: The experienced designer does not proliferate classes on a whim.  He
: does *exactly* what you have done.  He starts with a few classes, and
: then partition them according to their convenient abstractions.  

Should the developer partition according to "convenient abstractions"  for
"a few classes", gained at one phase of project iteration, and
incrementation or according to the overall architecture of the project
based on analysis vocabulary? 

: each partitioning, the designer ensures that the resultant code is
: simpler and more resilient to change. 

This is one goal of an iterative, incremental cycle.  There are others
also, such as coming closer to the vocabulary of the domain and 
fulfilling more project requirements.  Both of which may or may not 
require more classes.

: You saw me do this in my book.  In almost every case I would start
: with just a few simple core abstractions, and then I would hunt for
: the underlying abstractions that would allow me to partition the
: design to my advantage.

However the point of development is not only, or primarily gaining
advantage in terms of a lesser number of classes and their resilience to
change, in an effort to give the code designer an advantage.

Secondly here, how are underlying abstractions different from and more 
important than domain vocabulary abstractions?

Elliott

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]