🚀 go-pugleaf

In article <4i3vlj$jcs@netlab.cs.rpi.edu>, ell@access4.digex.net (Ell) writes:
|> 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       ]

In my experience each class you add costs a minimum of 500-1000 bytes
of memory (even for a dinky little class that doesn't have anything
except the compiler generated member functions).

I think it's a trade off between the strict type checking that 
classes provide versus the memory they waste.

For example you might create a RangedInt base class and then
derive classes from there with the specific ranges needed in
your program (each class would derive from a class with a greater
range).  Your compiler would prevent you from passing out of range
integers to your functions.  Of course it would get silly if you
have too many ranges.

That's kind of dumb example, but I think it illustrates the tradeoff.

- Bob
-- 
Robert Lister

      [ 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       ]