class size

[Larry Bates]

I doubt there is a hard-and-fast rule.  I think most
programmers tend to think of classes as representing
logical objects (things).  If those things contain
other things then they most likely need their own
class.

Example:

I recently wrote a inbound fax forwarding program
that had things like:

Network Neighborhood
    Fax Server (n-to a Neighborhood)
        Groups (n-to a Server)
            Rules (n-to a Group)
                Routes (n-to a Rule)

Since each of these were distinct things, they
each got a separate class.

Then I had:

Fax Queue (1-to a Server)
    Fax (n-to a Fax Queue)

Each of these got their own class.  That way the
methods and attributes for each of these was
distinct and it made it much easier to isolate
and debug my code.  By using iterators, I could
then write very straightforward code to loop over
each "thing".

Another reason to introduce a new class would be
if you want to abstract the interface to some
information.  That is hide the mechanics of some
interface behind a class so that it is easier
to change or to break it into smaller units that
are easier to understand.  I think this is what
you are referring to.  I personally don't like
classes that have over a couple of hundred lines
(but sometimes I "break" that rule).  The smaller
they are the easier they are to understand and
to debug.

Larry Bates


"Brad Tilley" <bradtilley at usa.net> wrote in message 
news:cipr3e$q72$1 at solaris.cc.vt.edu...
> How large (lines of code) should a class be before one should split it 
> into smaller classes? Is there a general rule on this? How many functions 
> should a class contain? Are there limits (theoretical or practical) that 
> people learning classes should adhere to?