On choosing classes.

Discussion in 'C++' started by Srinu, Aug 11, 2010.

  1. Srinu

    Srinu Guest

    Dear All,

    This is a unfortunate-problem of everyday life to every programmers.
    What are the simple guidelines to choose my classes for my problem?
    We would like to gather some thumb-rules from our own experience.

    This question arose, when I encounter two very different OOP approach.
    1. For every word uttered in the requirement, we can write a class.
    2. Most restrictive approach where it is forbidden to add one more
    class.

    Obviously, the above two approaches are not correct, for they
    represent two extremes.
    Question is now, where shall I stop adding more classes? What are the
    simple guidelines/thumb-rules to choose classes for my problem?

    Here interest is not on any particular type of problem. Guidelines
    need be very generic, applicable to all problems that can better be
    solved with OO technology.

    I will be happy to listen from your own experience.


    Sincerely,
    Srinivas Nayak
     
    Srinu, Aug 11, 2010
    #1
    1. Advertising

  2. On 8/11/2010 1:45 AM, Srinu wrote:
    > This is a unfortunate-problem of everyday life to every programmers.
    > What are the simple guidelines to choose my classes for my problem?


    There aren't any.

    > We would like to gather some thumb-rules from our own experience.
    >
    > This question arose, when I encounter two very different OOP approach.
    > 1. For every word uttered in the requirement, we can write a class.
    > 2. Most restrictive approach where it is forbidden to add one more
    > class.
    >
    > Obviously, the above two approaches are not correct, for they
    > represent two extremes.
    > Question is now, where shall I stop adding more classes? What are the
    > simple guidelines/thumb-rules to choose classes for my problem?
    >
    > Here interest is not on any particular type of problem. Guidelines
    > need be very generic, applicable to all problems that can better be
    > solved with OO technology.
    >
    > I will be happy to listen from your own experience.


    From experience: ask in comp.object.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 11, 2010
    #2
    1. Advertising

  3. Srinu <>, on 10/08/2010 22:45:03, wrote:

    > Dear All,
    >
    > This is a unfortunate-problem of everyday life to every programmers.
    > What are the simple guidelines to choose my classes for my problem?
    > We would like to gather some thumb-rules from our own experience.
    >
    > This question arose, when I encounter two very different OOP approach.
    > 1. For every word uttered in the requirement, we can write a class.
    > 2. Most restrictive approach where it is forbidden to add one more
    > class.
    >
    > Obviously, the above two approaches are not correct, for they
    > represent two extremes.
    > Question is now, where shall I stop adding more classes? What are the
    > simple guidelines/thumb-rules to choose classes for my problem?
    >
    > Here interest is not on any particular type of problem. Guidelines
    > need be very generic, applicable to all problems that can better be
    > solved with OO technology.
    >
    > I will be happy to listen from your own experience.


    There isn't any universal set of rules and there isn't any universal set
    of guidelines, though there are many of non-universal ones in practice.

    Bjarne Stroustrup gives some guidelines in TC++PL, but he stresses the
    point that those guidelines are just that, guidelines, and that the most
    important thing is using one's experience and common sense when making a
    decision, without resorting to blindly follow any set of rules.

    I think there could be some context where some rules are set and
    expected to be followed, but those things would be "internal stuff" of
    some developing team or company.

    Personally, I find Bjarne's guidelines quite good and I use them as a
    reference when I'm stuck on some design decision.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Aug 11, 2010
    #3
  4. On 8/11/2010 9:34 AM, Francesco S. Carta wrote:
    > Srinu <>, on 10/08/2010 22:45:03, wrote:
    >> This is a unfortunate-problem of everyday life to every programmers.
    >> What are the simple guidelines to choose my classes for my problem?
    >> We would like to gather some thumb-rules from our own experience.
    >>
    >> This question arose, when I encounter two very different OOP approach.
    >> 1. For every word uttered in the requirement, we can write a class.
    >> 2. Most restrictive approach where it is forbidden to add one more
    >> class.
    >> [..]

    >
    > Bjarne Stroustrup gives some guidelines in TC++PL, but he stresses the
    > point that those guidelines are just that, guidelines, and that the most
    > important thing is using one's experience and common sense when making a
    > decision, without resorting to blindly follow any set of rules.
    >
    > I think there could be some context where some rules are set and
    > expected to be followed, but those things would be "internal stuff" of
    > some developing team or company.
    >
    > Personally, I find Bjarne's guidelines quite good and I use them as a
    > reference when I'm stuck on some design decision.
    >


    Since we're recommending books with guidelines, try "Advanced C++" by
    James Coplien.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 11, 2010
    #4
  5. Srinu

    Jeff Flinn Guest

    Srinu wrote:
    > Dear All,
    >
    > This is a unfortunate-problem of everyday life to every programmers.
    > What are the simple guidelines to choose my classes for my problem?
    > We would like to gather some thumb-rules from our own experience.
    >
    > This question arose, when I encounter two very different OOP approach.
    > 1. For every word uttered in the requirement, we can write a class.
    > 2. Most restrictive approach where it is forbidden to add one more
    > class.
    >
    > Obviously, the above two approaches are not correct, for they
    > represent two extremes.
    > Question is now, where shall I stop adding more classes? What are the
    > simple guidelines/thumb-rules to choose classes for my problem?
    >
    > Here interest is not on any particular type of problem. Guidelines
    > need be very generic, applicable to all problems that can better be
    > solved with OO technology.
    >
    > I will be happy to listen from your own experience.


    See Object-Oriented Software Construction by Bertrand Meyer.

    Jeff
     
    Jeff Flinn, Aug 11, 2010
    #5
  6. Srinu

    Öö Tiib Guest

    On Aug 11, 8:45 am, Srinu <> wrote:
    > This is a unfortunate-problem of everyday life to every programmers.
    > What are the simple guidelines to choose my classes for my problem?
    > We would like to gather some thumb-rules from our own experience.


    Perfect thing is durable, well-performing, cheap and light, not
    inherently broken and even hard to break. Like wing of dragonfly. You
    can not remove anything from wing of dragonfly without breaking it nor
    add anything without making it worse and it is hard to find cheaper
    and lighter materials for constructing it.

    There is only one thumb-rule of how to construct something as perfect
    like that ... be a god and have lot of time.

    There are no gods in software industry. There are ordinary mortal
    people and for herding them away from major mistakes lots of (pretty
    fragile and contradicting with each other) concepts have been produced
    over time. One subset of such concepts is called "object-oriented
    programming" (it is also fragile and contradicting set).

    There are no gods in your team. You may need experienced architect,
    surgeon-general or lead-developer who helps to enforce set of rules
    what is good OO in his/her team and what is not. Avoid having too
    several hot-gun peers, their views may contradict and bloody battles
    may emerge.

    If you want to be one of such leaders then read a lot of books (about
    object oriented and other programming concepts) and practice a lot.
    Participate as developer in large teams in several projects from very
    various fields over years. Some 20 years later you have a strong set
    of detailed views what is OO of your own. You are god-like enough for
    people who just started.

    Alternatively you may come here into comp.lang.c++ and discuss the
    concepts with others. You can get contradicting opinions for any topic
    if you like that sort of amusement.
     
    Öö Tiib, Aug 12, 2010
    #6
  7. Öö Tiib <>, on 12/08/2010 05:14:35, wrote:

    > On Aug 11, 8:45 am, Srinu<> wrote:
    >> This is a unfortunate-problem of everyday life to every programmers.
    >> What are the simple guidelines to choose my classes for my problem?
    >> We would like to gather some thumb-rules from our own experience.

    >
    > Perfect thing is durable, well-performing, cheap and light, not
    > inherently broken and even hard to break. Like wing of dragonfly. You
    > can not remove anything from wing of dragonfly without breaking it nor
    > add anything without making it worse and it is hard to find cheaper
    > and lighter materials for constructing it.


    Nice image!

    > There is only one thumb-rule of how to construct something as perfect
    > like that ... be a god and have lot of time.


    Being a god is enough, all the rest comes as a consequence ;-)

    > There are no gods in software industry. There are ordinary mortal
    > people and for herding them away from major mistakes lots of (pretty
    > fragile and contradicting with each other) concepts have been produced
    > over time. One subset of such concepts is called "object-oriented
    > programming" (it is also fragile and contradicting set).
    >
    > There are no gods in your team. You may need experienced architect,
    > surgeon-general or lead-developer who helps to enforce set of rules
    > what is good OO in his/her team and what is not. Avoid having too
    > several hot-gun peers, their views may contradict and bloody battles
    > may emerge.
    >
    > If you want to be one of such leaders then read a lot of books (about
    > object oriented and other programming concepts) and practice a lot.
    > Participate as developer in large teams in several projects from very
    > various fields over years. Some 20 years later you have a strong set
    > of detailed views what is OO of your own. You are god-like enough for
    > people who just started.
    >
    > Alternatively you may come here into comp.lang.c++ and discuss the
    > concepts with others. You can get contradicting opinions for any topic
    > if you like that sort of amusement.


    I find such debates with contradicting opinions rather interesting,
    maybe not always amusing, but interesting, yes.

    The points you listed are quite good IMO.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Aug 12, 2010
    #7
  8. Srinu

    Guest

    On 8月11æ—¥, 下åˆ1時45分, Srinu <> wrote:
    > Dear All,
    >
    > This is a unfortunate-problem of everyday life to every programmers.
    > What are the simple guidelines to choose my classes for my problem?
    > We would like to gather some thumb-rules from our own experience.
    >
    > This question arose, when I encounter two very different OOP approach.
    > 1. For every word uttered in the requirement, we can write a class.
    > 2. Most restrictive approach where it is forbidden to add one more
    > class.
    >
    > Obviously, the above two approaches are not correct, for they
    > represent two extremes.
    > Question is now, where shall I stop adding more classes? What are the
    > simple guidelines/thumb-rules to choose classes for my problem?
    >
    > Here interest is not on any particular type of problem. Guidelines
    > need be very generic, applicable to all problems that can better be
    > solved with OO technology.
    >
    > I will be happy to listen from your own experience.
    >
    > Sincerely,
    > Srinivas Nayak

    If you are looking for a practical guideline to design your class.
    There is one in http://sourceforge.net/projects/cscall/
    The reset rule is in principle very generic, applicable to vast
    amount of classes. Note that I mean in principle.
    The reset rule is derived from the first rule of designing a class,
    i.e. making sure object constructed can be safely destructed.
    Try it, don't be fooled by its simplicity,
     
    , Aug 12, 2010
    #8
  9. , on 12/08/2010 08:42:57, wrote:

    > On 8月11æ—¥, 下åˆ1時45分, Srinu<> wrote:
    >> Dear All,
    >>
    >> This is a unfortunate-problem of everyday life to every programmers.
    >> What are the simple guidelines to choose my classes for my problem?
    >> We would like to gather some thumb-rules from our own experience.
    >>
    >> This question arose, when I encounter two very different OOP approach.
    >> 1. For every word uttered in the requirement, we can write a class.
    >> 2. Most restrictive approach where it is forbidden to add one more
    >> class.
    >>
    >> Obviously, the above two approaches are not correct, for they
    >> represent two extremes.
    >> Question is now, where shall I stop adding more classes? What are the
    >> simple guidelines/thumb-rules to choose classes for my problem?
    >>
    >> Here interest is not on any particular type of problem. Guidelines
    >> need be very generic, applicable to all problems that can better be
    >> solved with OO technology.
    >>
    >> I will be happy to listen from your own experience.
    >>
    >> Sincerely,
    >> Srinivas Nayak

    > If you are looking for a practical guideline to design your class.
    > There is one in http://sourceforge.net/projects/cscall/
    > The reset rule is in principle very generic, applicable to vast
    > amount of classes. Note that I mean in principle.
    > The reset rule is derived from the first rule of designing a class,
    > i.e. making sure object constructed can be safely destructed.
    > Try it, don't be fooled by its simplicity,


    Are you referring to the "Rationale.txt" file within the archive
    downloadable from the page you linked?

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Aug 12, 2010
    #9
  10. Srinu

    Guest

    On 8月12æ—¥, 下åˆ11時57分, "Francesco S. Carta" <> wrote:
    > , on 12/08/2010 08:42:57, wrote:
    >
    >
    >
    > > On 8月11æ—¥, 下åˆ1時45分, Srinu<>  wrote:
    > >> Dear All,

    >
    > >> This is a unfortunate-problem of everyday life to every programmers.
    > >> What are the simple guidelines to choose my classes for my problem?
    > >> We would like to gather some thumb-rules from our own experience.

    >
    > >> This question arose, when I encounter two very different OOP approach.
    > >> 1. For every word uttered in the requirement, we can write a class.
    > >> 2. Most restrictive approach where it is forbidden to add one more
    > >> class.

    >
    > >> Obviously, the above two approaches are not correct, for they
    > >> represent two extremes.
    > >> Question is now, where shall I stop adding more classes? What are the
    > >> simple guidelines/thumb-rules to choose classes for my problem?

    >
    > >> Here interest is not on any particular type of problem. Guidelines
    > >> need be very generic, applicable to all problems that can better be
    > >> solved with OO technology.

    >
    > >> I will be happy to listen from your own experience.

    >
    > >> Sincerely,
    > >> Srinivas Nayak

    > > If you are looking for a practical guideline to design your class.
    > > There is one inhttp://sourceforge.net/projects/cscall/
    > > The reset rule is in principle very generic, applicable to vast
    > > amount of classes. Note that I mean in principle.
    > > The reset rule is derived from the first rule of designing a class,
    > > i.e. making sure object constructed can be safely destructed.
    > > Try it, don't be fooled by its simplicity,

    >
    > Are you referring to the "Rationale.txt" file within the archive
    > downloadable from the page you linked?
    >
    > --
    >   FSC -http://userscripts.org/scripts/show/59948
    >  http://fscode.altervista.org-http://sardinias.com

    Yes, at the end of that file. It is written some time ago.
     
    , Aug 12, 2010
    #10
  11. , on 12/08/2010 09:05:55, wrote:

    > On 8月12æ—¥, 下åˆ11時57分, "Francesco S. Carta"<> wrote:
    >> , on 12/08/2010 08:42:57, wrote:
    >>
    >>
    >>
    >>> On 8月11æ—¥, 下åˆ1時45分, Srinu<> wrote:
    >>>> Dear All,

    >>
    >>>> This is a unfortunate-problem of everyday life to every programmers.
    >>>> What are the simple guidelines to choose my classes for my problem?
    >>>> We would like to gather some thumb-rules from our own experience.

    >>
    >>>> This question arose, when I encounter two very different OOP approach.
    >>>> 1. For every word uttered in the requirement, we can write a class.
    >>>> 2. Most restrictive approach where it is forbidden to add one more
    >>>> class.

    >>
    >>>> Obviously, the above two approaches are not correct, for they
    >>>> represent two extremes.
    >>>> Question is now, where shall I stop adding more classes? What are the
    >>>> simple guidelines/thumb-rules to choose classes for my problem?

    >>
    >>>> Here interest is not on any particular type of problem. Guidelines
    >>>> need be very generic, applicable to all problems that can better be
    >>>> solved with OO technology.

    >>
    >>>> I will be happy to listen from your own experience.

    >>
    >>>> Sincerely,
    >>>> Srinivas Nayak
    >>> If you are looking for a practical guideline to design your class.
    >>> There is one inhttp://sourceforge.net/projects/cscall/
    >>> The reset rule is in principle very generic, applicable to vast
    >>> amount of classes. Note that I mean in principle.
    >>> The reset rule is derived from the first rule of designing a class,
    >>> i.e. making sure object constructed can be safely destructed.
    >>> Try it, don't be fooled by its simplicity,

    >>
    >> Are you referring to the "Rationale.txt" file within the archive
    >> downloadable from the page you linked?


    [ please snip out signatures when quoting ]

    > Yes, at the end of that file. It is written some time ago.


    I see. The file is interesting, though the OP seemed to be looking for
    guidelines about when to create classes, not about how to create them,
    just for the records.

    Never mind, I've posted the above just to point out the exact position
    of the resource ;-)

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Aug 12, 2010
    #11
  12. Srinu

    Phlip Guest

    On Aug 11, 7:59 pm, "Daniel T." <> wrote:

    > I agree with Victor. Anybody who could explain something like this in
    > the standard length of a newsgroup post doesn't know what he's talking
    > about.


    Write unit tests so you can refactor, then the question is less
    important.

    A clean design...

    - passes all tests
    - is clear and readable
    - duplicates no definitions of behavior
    - minimizes lines, methods, and classes

    That stuff could fill many books, but the rubric itself fits one
    newsgroup post.

    And note the list does not say "Open Closed Principle", "Liskov
    Substitution Principle", "Encapsulation is Hierarchical", "Contractive
    Delegation", or any other high-level goals. That's why they are goals;
    enforcing those simplicity rules should help them emerge.
     
    Phlip, Aug 23, 2010
    #12
  13. Srinu

    Richard Guest

    [Please do not mail me a copy of your followup]

    Phlip <> spake the secret code
    <> thusly:

    >Write unit tests so you can refactor, then the question is less
    >important.


    In addition: write the tests first and relentlessly eliminate
    duplication and you pretty much end up with the design Phlip
    describes.
    --
    "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
    <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

    Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
     
    Richard, Aug 23, 2010
    #13
  14. Srinu

    Phlip Guest

    On Aug 22, 9:02 pm, (Richard) wrote:
    > [Please do not mail me a copy of your followup]
    >
    > Phlip <> spake the secret code
    > <> thusly:
    >
    > >Write unit tests so you can refactor, then the question is less
    > >important.

    >
    > In addition: write the tests first and relentlessly eliminate
    > duplication and you pretty much end up with the design Phlip
    > describes.


    Tx for the bump. Too often when someone posts "What's the best design
    to X?" they seem to really post "I have only one chance to get this
    design right, because I have no unit tests and can never safely
    refactor it..."

    I'll be good now!
     
    Phlip, Aug 23, 2010
    #14
  15. Srinu

    Richard Guest

    [Please do not mail me a copy of your followup]

    Phlip <> spake the secret code
    <> thusly:

    >Tx for the bump. Too often when someone posts "What's the best design
    >to X?" they seem to really post "I have only one chance to get this
    >design right, because I have no unit tests and can never safely
    >refactor it..."


    I agree. I found I had more personal comfort and freedom once I
    started practicing test-driven development. (See
    <http://tinyurl.com/ns4bvx> for a tutorial on test-driven development
    with C++ and Boost.Test.)

    I had fewer bugs. I tended to have more classes, but they were more
    focused and had a single well defined responsibility. I had less
    duplication. Because my classes were smaller, easier to understand
    and had a focused role, I found it easier to reuse them in other
    contexts. I also felt that my designs were better, even though I
    "evolved" them instead of planning them all out up-front. I still
    think ahead and do planning, but not so much all the nagging little
    details. I do planning and design ahead in broad strokes and let the
    tests tell me the details. The unit tests gave me a sense of
    confidence in the changes I had made and I never worried about
    checking my code in anymore. In general, life was just better.

    It takes a while to get into the test-first rhythm, but its a very
    rewarding feeling once you get there.
    --
    "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
    <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

    Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
     
    Richard, Aug 23, 2010
    #15
  16. On 11 Aug, 06:45, Srinu <> wrote:

    > What are the simple guidelines to choose my classes for my problem?

    [...]
    > 1. For every word uttered in the requirement, we can write a class.


    I like this one. Imagine a class for "the" or "and"...

    :)
     
    Nick Keighley, Aug 31, 2010
    #16
  17. Srinu

    Jorgen Grahn Guest

    On Mon, 2010-08-30, Thomas Gagne wrote:
    > True, you can't explain it all in a newsgroup post, but I believe many
    > make it out to be more difficult than it needs to be, including the books.
    >
    > I recommend taking a /small/ domain you know well, and building it up
    > from scratch. Better if you can do it with someone. If not, find
    > someone you can show it to after to get their input.
    >
    > Personally, the best advice I ever got on OO design came from
    > Smalltalkers. There's few-enough of them that most you'll find will be
    > better than your average Java or C# programmer (IMO).


    Note that the question was originally posted in comp.lang.c++.

    I don't doubt that the Smalltalk programmers are good at what they do,
    but it seems risky to apply their advice straight to C++ design. They're
    very different languages, and what's obviously the right design in one
    of them may be a terrible choice in the other.

    For example, my C++ designs rely heavily on static type checking and
    the lack of cost for creating and using many small objects. My Python
    designs look rather different.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Aug 31, 2010
    #17
    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. Ranjith
    Replies:
    0
    Views:
    2,499
    Ranjith
    Nov 25, 2003
  2. ALuPin

    Choosing PLL

    ALuPin, Jul 28, 2004, in forum: VHDL
    Replies:
    1
    Views:
    695
    Subroto Datta
    Jul 28, 2004
  3. John
    Replies:
    0
    Views:
    299
  4. nospam
    Replies:
    13
    Views:
    616
  5. omair

    choosing an IIS server

    omair, Nov 17, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    314
    omair
    Nov 17, 2003
Loading...

Share This Page