On choosing classes.

[Srinu]

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

 

[Victor Bazarov]

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

 

[Francesco S. Carta]

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.

 

[Victor Bazarov]

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

 

[Jeff Flinn]

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

 

[Öö Tiib]

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.

 

[Francesco S. Carta]

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.

 

[wij]

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,

 

[Francesco S. Carta]

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?

 

[wij]

(e-mail address removed), on 12/08/2010 08:42:57, wrote:




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

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

 

[Francesco S. Carta]

[ 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 ;-)

 

[Phlip]

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.

 

[Richard]

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

Phlip <[email protected]> spake the secret code

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.

 

[Phlip]

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

Phlip <[email protected]> spake the secret code

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!

 

[Richard]

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

Phlip <[email protected]> spake the secret code

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.

 

[Nick Keighley]

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"...

 

[Jorgen Grahn]

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