design issues: variables at class scope

Discussion in 'C++' started by Neil Zanella, Oct 11, 2003.

  1. Neil Zanella

    Neil Zanella Guest

    Hello,

    It seems to me that using too many variables at class scope in C++ (e.g.
    private data members) can be just as bad as having a C program with lots
    of global variables. This is especially true for large classes with
    lots of methods. The worse part is that even if conventions are used
    to assign names to class data members to so as to distinguish them from
    other variables, then it still becomes difficult to tell from the
    class definition which methods use which variables without looking
    at the particular implementation of functions. That is, when we
    look at a header file, it is fairly difficult if not impossible
    to tell which methods use which data members. This makes it
    especially difficult to refactor code. All of this leads me
    to wonder whether it is best to pass data members of the
    class so as to make it clear which methods use which
    variables, and make the methods static. This makes
    it really clear to tell which methods use which
    private data members: since the methods are
    static, they must appear in the parameter
    list to the function.

    Comments, opinions, and suggestions welcome,

    Thanks,

    Neil
     
    Neil Zanella, Oct 11, 2003
    #1
    1. Advertising

  2. Neil Zanella

    Phlip Guest

    Neil Zanella wrote:

    > It seems to me that using too many variables at class scope in C++ (e.g.
    > private data members) can be just as bad as having a C program with lots
    > of global variables.


    Hmm. So I whip out my copy of /Refactoring/ by Martin Fowler, and find this
    situation is "Data Clumps", indicating the refactor "Extract Class".

    Are one or two small classes trapped inside your big class, waiting to come
    out?

    > This is especially true for large classes with
    > lots of methods. The worse part is that even if conventions are used
    > to assign names to class data members to so as to distinguish them from
    > other variables, then it still becomes difficult to tell from the
    > class definition which methods use which variables without looking
    > at the particular implementation of functions.


    Why is knowing this important? Don't the names of the methods reveal their
    intent (per /Smalltalk Best Practice Patterns/ by Kent Beck)?

    > That is, when we
    > look at a header file, it is fairly difficult if not impossible
    > to tell which methods use which data members. This makes it
    > especially difficult to refactor code. All of this leads me
    > to wonder whether it is best to pass data members of the
    > class so as to make it clear which methods use which
    > variables, and make the methods static. This makes
    > it really clear to tell which methods use which
    > private data members: since the methods are
    > static, they must appear in the parameter
    > list to the function.


    Okay, start backwards. Which of these methods are private? Which can demote
    to static free functions at file scope in the .cpp file?

    The book /Large Scale C++ Software Design/ covers hiding the large aspects
    of a program. (/Refactoring/, and /Agile Software Development/ by Robert
    Martin cover making the program not large.)

    If you can find some set of methods that access generally the same set of
    member variables, that is your latent class. Pulling that out into a new
    class (inside the same header file, at first) will give you one more place
    to name what's going on - the name of the new class.

    --
    Phlip
    http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
     
    Phlip, Oct 11, 2003
    #2
    1. Advertising

  3. "Neil Zanella" <> wrote in message
    news:p...
    >
    > Hello,
    >
    > It seems to me that using too many variables at class scope in C++ (e.g.
    > private data members) can be just as bad as having a C program with lots
    > of global variables.


    [Snip]

    > Comments, opinions, and suggestions welcome,


    I utterly agree with you, this applies to C and C++ programs alike.

    I am not a design expert, but in my view
    the condition 'too-many-variables-at-class-scope' indicates a violation of
    the rule 'one-class = one-real-life-representation'.

    That means that you should always ask yourself whether the real life
    representation (of what you are going to design as a C++-class) can not be
    broken down / re-designed better in real life. You should attempt to build
    the C++-classes only after you are satisfied that the real-life
    representation is your final choice. In my view, trying to design a
    C++-class strictly on the grounds of language rules leads to disaster.

    The only language-related comment I would like to make is that the C++
    language offers a multitude of different techniques to combine classes:
    inheritance, composition, generic programming, etc... The coice of the
    technique is yours, but only *after* you have decided about the real-life
    representation.

    >
    > Thanks,
    >
    > Neil
    >
     
    Klaus Eichner, Oct 11, 2003
    #3
  4. Neil Zanella

    Phlip Guest

    Klaus Eichner wrote:

    > I am not a design expert, but in my view
    > the condition 'too-many-variables-at-class-scope' indicates a violation of
    > the rule 'one-class = one-real-life-representation'.


    You have a guideline in mind that some call "separation of concerns".

    But some poorly-written OO tutorials begin by describing Objects as "models
    of real-world objects".

    That adds no value because it's not distinct. If you and I want to assess
    two designs to figure out which is better to use, we can't select between
    them because one "more closely matches the real world".

    The best guidelines for a design are...

    1. passes all test
    2. readable code
    3. no duplication
    4. minimal class & method sizes

    The OP admits breaking 4, so the odds they break 3 are very high.

    And no design once implemented is set in stone - it can always be improved.

    --
    Phlip
     
    Phlip, Oct 11, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Opal
    Replies:
    12
    Views:
    976
    Paul Opal
    Oct 11, 2004
  2. Steven T. Hatton
    Replies:
    9
    Views:
    505
  3. ManicQin
    Replies:
    0
    Views:
    292
    ManicQin
    Feb 9, 2009
  4. jrobinss

    inner class scope issues

    jrobinss, Mar 23, 2009, in forum: Java
    Replies:
    20
    Views:
    1,025
  5. Talha Oktay
    Replies:
    8
    Views:
    222
Loading...

Share This Page