«

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

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

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

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

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

On Aug 11, 8:45*am, Srinu <sinu.nayak2...@gmail.com> 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 <>, on 12/08/2010 05:14:35, wrote:

> On Aug 11, 8:45 am, Srinu<sinu.nayak2...@gmail.com> 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

On 8月11日, 下�1時45分, Srinu <sinu.nayak2...@gmail.com> 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,

, on 12/08/2010 08:42:57, wrote:

> On 8月11日, 下�1時45分, Srinu<sinu.nayak2...@gmail.com> 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

On 8月12日, 下�11時57分, "Francesco S. Carta" <entul...@gmail.com> wrote:
> w...@seed.net.tw, on 12/08/2010 08:42:57, wrote:
>
>
>
> > On 8月11æ—¥, 下å�ˆ1時45分, Srinu<sinu.nayak2...@gmail.com> Â*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.