Class design issue

[crea]

Lets say we are programming a wheather data analysing and display program
(of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions regarding
analysing data. So this data (it contains the data) can be passed to CChart
to draw it.

Now we want combine these two to draw a chart with data in it. Is it better
to create a new class which inherits from them like this:

1)
class CWheatherChart : public CChart, public CWheather
{
....
};

or create a class which inludes them as members like this:

2)
class CWheatherChart
{
CChart m_Chart;
CWheather m_Wheather;
....
};

(The point is, that later on we can create specific classes for example to
moon-wheather , earth wheather, summer wheather... etc. which are inherited
from CWheatherChart:

class CMoonWheatherChart : public CWheatherChart)

These two classes must communicate with eatch others sometimes as doing
steps, like when the chart draws a certain data value (x,y) it might ask
something from CWheather class in the middle of its drawing. So using the
design 1) we could use virtual functions to handle this (having virtual
function for data draw in CChart and then have also it on CWheatherChart ).

Which way is better? I guess 1) makes things a bit easier to program (can
use virtual functions to communicate between CChart and CWheather ), but on
the other hand 2) gives possibility to change easily chart or data on the
fly.

 

[Victor Bazarov]

Lets say we are programming a wheather data analysing and display program
(of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions regarding
analysing data. So this data (it contains the data) can be passed to CChart
to draw it.

BTW, the English word 'weather' does not have the 'h' following 'w'...

Now we want combine these two to draw a chart with data in it. Is it better
to create a new class which inherits from them like this:

1)
class CWheatherChart : public CChart, public CWheather
{
...
};

or create a class which inludes them as members like this:

2)
class CWheatherChart
{
CChart m_Chart;
CWheather m_Wheather;
...
};

(The point is, that later on we can create specific classes for example to
moon-wheather , earth wheather, summer wheather... etc. which are inherited
from CWheatherChart:

class CMoonWheatherChart : public CWheatherChart)

These two classes must communicate with eatch others sometimes as doing
steps, like when the chart draws a certain data value (x,y) it might ask
something from CWheather class in the middle of its drawing. So using the
design 1) we could use virtual functions to handle this (having virtual
function for data draw in CChart and then have also it on CWheatherChart ).

Which way is better? I guess 1) makes things a bit easier to program (can
use virtual functions to communicate between CChart and CWheather ), but on
the other hand 2) gives possibility to change easily chart or data on the
fly.

First off, both 1) and 2) provide the changeability of 'CChart' and
'CWheather' part, since, technically speaking, they are contained within
your 'CWheatherChart' in either case.

Public inheritance has the additional perk - the possibility to use your
derived class where the base class is expected - LSP (look it up). The
containment does not have that.

You have not provided any detailed explanation on how your classes are
going to be used, and *only that* should drive the design.

Also, post to 'comp.object' to learn more about OOD.

V

 

[crea]

Also, post to 'comp.object' to learn more about OOD.

V

I continue there..

 

[Alf P. Steinbach /Usenet]

* crea, on 03.03.2011 13:43:

Lets say we are programming a wheather data analysing and display program
(of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions regarding
analysing data. So this data (it contains the data) can be passed to CChart
to draw it.

Presumably[1] the "C" signifies "Constant"?

Now we want combine these two to draw a chart with data in it. Is it better
to create a new class which inherits from them like this:

1)
class CWheatherChart : public CChart, public CWheather
{
...
};

or create a class which inludes them as members like this:

2)
class CWheatherChart
{
CChart m_Chart;
CWheather m_Wheather;
...
};

No.

In the first case you are saying that a constant weather chart is a constant
weather. That doesn't make sense to me. In the second case you are copy a
constant weather to each constant weather chart, and that doesn't make much
sense (although it might, if your weathers are really small weathers).

Anyway, define your notion of "better".

(The point is, that later on we can create specific classes for example to
moon-wheather , earth wheather, summer wheather... etc. which are inherited
from CWheatherChart:

class CMoonWheatherChart : public CWheatherChart)

These two classes must communicate with eatch others

Well, tehcnically classes don't communicate: instances of them may communicate.

sometimes as doing
steps, like when the chart draws a certain data value (x,y) it might ask
something from CWheather class in the middle of its drawing. So using the
design 1) we could use virtual functions to handle this (having virtual
function for data draw in CChart and then have also it on CWheatherChart ).


Which way is better? I guess 1) makes things a bit easier to program (can
use virtual functions to communicate between CChart and CWheather ), but on
the other hand 2) gives possibility to change easily chart or data on the
fly.

Define resposibilities, put knowledge where it's needed, remember that
indirection is the solution to any computer science problem.

Cheers & hth.,

- Alf


Notes:
[1] I'm discounting the low-probability possibility that you're mindlessly
copying the meaningless and counter-productive Microsoft convention of appending
a misleading and meaningless prefix to every name.

 

[crea]

* crea, on 03.03.2011 13:43:

Lets say we are programming a wheather data analysing and display
program (of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can be
passed to CChart to draw it.

Presumably[1] the "C" signifies "Constant"?

No, it means "class" (CWheather = "class Wheather"). They are 2 normal
classes...

 

[Victor Bazarov]

* crea, on 03.03.2011 13:43:

Lets say we are programming a wheather data analysing and display
program (of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can be
passed to CChart to draw it.

Presumably[1] the "C" signifies "Constant"?

No, it means "class" (CWheather = "class Wheather"). They are 2 normal
classes...

Alf was teasing you (see his footnote). Microsoft's habit of putting
'C' in front of all their classes is surely contagious, isn't it?

V

 

[crea]

* crea, on 03.03.2011 13:43:
Lets say we are programming a wheather data analysing and display
program (of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can
be passed to CChart to draw it.

Presumably[1] the "C" signifies "Constant"?

No, it means "class" (CWheather = "class Wheather"). They are 2
normal classes...

Alf was teasing you (see his footnote). Microsoft's habit of putting
'C' in front of all their classes is surely contagious, isn't it?

V

yes, They use C. But I think its quite logical... C like class... This was
you know its a class type.

 

[Victor Bazarov]

Alf P. Steinbach /Usenet wrote:
* crea, on 03.03.2011 13:43:
Lets say we are programming a wheather data analysing and display
program (of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can
be passed to CChart to draw it.

Presumably[1] the "C" signifies "Constant"?


No, it means "class" (CWheather = "class Wheather"). They are 2
normal classes...

Alf was teasing you (see his footnote). Microsoft's habit of putting
'C' in front of all their classes is surely contagious, isn't it?

V

yes, They use C. But I think its quite logical... C like class... This was
you know its a class type.

There is nothing logical in that. It's called "monkey see, monkey do".
Do you use other "Hungarian notation" elements as well? Do you have
all your int variables' names start with 'i'? All doubles start with
'd'? Or some other similar nonsense? What if the type changes from
double to float or from int to unsigned long? Do you go renaming all
your affected variables?

V

 

[crea]

On 3/3/2011 9:27 AM, crea wrote:
Alf P. Steinbach /Usenet wrote:
* crea, on 03.03.2011 13:43:
Lets say we are programming a wheather data analysing and display
program (of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can
be passed to CChart to draw it.

Presumably[1] the "C" signifies "Constant"?


No, it means "class" (CWheather = "class Wheather"). They are 2
normal classes...

Alf was teasing you (see his footnote). Microsoft's habit of
putting 'C' in front of all their classes is surely contagious,
isn't it? V

yes, They use C. But I think its quite logical... C like class...
This was you know its a class type.

There is nothing logical in that. It's called "monkey see, monkey
do". Do you use other "Hungarian notation" elements as well? Do you

yes, its good to know what type it is. I think many professionals use this.

have all your int variables' names start with 'i'? All doubles start

with integers its "n".

with 'd'? Or some other similar nonsense? What if the type changes
from double to float or from int to unsigned long? Do you go

this happens very rarely in practical applications. Dont remember when
happened to me.

renaming all your affected variables?

from double to float its not that big issue bce both are decimal numbers

 

[Victor Bazarov]

Victor Bazarov wrote:
On 3/3/2011 9:27 AM, crea wrote:
Alf P. Steinbach /Usenet wrote:
* crea, on 03.03.2011 13:43:
Lets say we are programming a wheather data analysing and display
program (of course using VC!).

We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can
be passed to CChart to draw it.

Presumably[1] the "C" signifies "Constant"?


No, it means "class" (CWheather = "class Wheather"). They are 2
normal classes...

Alf was teasing you (see his footnote). Microsoft's habit of
putting 'C' in front of all their classes is surely contagious,
isn't it? V

yes, They use C. But I think its quite logical... C like class...
This was you know its a class type.

There is nothing logical in that. It's called "monkey see, monkey
do". Do you use other "Hungarian notation" elements as well? Do you

yes, its good to know what type it is. I think many professionals use this.
[..]

"Many" as in hundreds/thousands? Or "many" as in seventy-five percent?
*All* professionals *I know* discourage use of type prefix. BTW, do
you use 'T' or 'CT' for class templates? What about functions? Do you
use prefix to indicate what type it returns or what type it has
(including the arguments)?

V

 

[crea]

"Many" as in hundreds/thousands? Or "many" as in seventy-five
percent? *All* professionals *I know* discourage use of type prefix.
BTW, do you use 'T' or 'CT' for class templates? What about
functions? Do you use prefix to indicate what type it returns or
what type it has (including the arguments)?

With functions you see it automatically because the parameters are using
prefixs. Like this:

int nCount;
string strName;

Foo(nCount, strName);

Now, we dont need to put it to Foo, because we can see that what types they
are according to variables. So we know that the first Foo parameter is int
because of nCount.

 

[crea]

On 3/3/2011 12:14 PM, crea wrote:
"Many" as in hundreds/thousands? Or "many" as in seventy-five
percent? *All* professionals *I know* discourage use of type prefix.
BTW, do you use 'T' or 'CT' for class templates? What about
functions? Do you use prefix to indicate what type it returns or
what type it has (including the arguments)?

For example with global integer you could use:

int g_nCounter;

Just looking the name you know its global AND its an integer. Handy ... .

If you put m_, that would mean a class memeber

 

[James Kanze]

Alf P. Steinbach /Usenet wrote:
* crea, on 03.03.2011 13:43:
Lets say we are programming a wheather data analysing and display
program (of course using VC!).
We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can
be passed to CChart to draw it.
Presumably[1] the "C" signifies "Constant"?
No, it means "class" (CWheather = "class Wheather"). They are 2
normal classes...

Alf was teasing you (see his footnote). Microsoft's habit of putting
'C' in front of all their classes is surely contagious, isn't it?

yes, They use C. But I think its quite logical... C like class... This was
you know its a class type.

And what types with e.g. member functions and private data
aren't class types?

In fact, the Microsoft convention is used for functions in MFC,
it's a private prefix (MFC predates namespaces), used to avoid
the risk of name collisions with user classes (which, of course,
should never be prefixed with a C.) It's not a good
convention---it's too short---but it was common practice back
then to use some sort of convention when providing librarys to
a large community of users.

 

[James Kanze]

Victor Bazarov wrote:
On 3/3/2011 9:27 AM, crea wrote:
Alf P. Steinbach /Usenet wrote:
* crea, on 03.03.2011 13:43:
Lets say we are programming a wheather data analysing and display
program (of course using VC!).
We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can
be passed to CChart to draw it.
Presumably[1] the "C" signifies "Constant"?
No, it means "class" (CWheather = "class Wheather"). They are 2
normal classes...
Alf was teasing you (see his footnote). Microsoft's habit of
putting 'C' in front of all their classes is surely contagious,
isn't it? V
yes, They use C. But I think its quite logical... C like class...
This was you know its a class type.

There is nothing logical in that. It's called "monkey see, monkey
do". Do you use other "Hungarian notation" elements as well? Do you

yes, its good to know what type it is. I think many professionals use this.

Actually, it's an almost certain indicator of an amateur. The
type is Chart, or Weather, or whatever.

with integers its "n".

this happens very rarely in practical applications. Dont remember when
happened to me.

I don't think I've ever worked on an application where it didn't
happen. Applications live.

from double to float its not that big issue bce both are decimal numbers

Neither is decimal, at least not on any platform I know. (Most
platforms today, except mainframes, use binary. IBM mainframes
use hexadecimal, and Unisys mainframes octal. The IBM 1401 did
use decimal, but I don't think that there was ever a C++
compiler for it.)

 

[Jorgen Grahn]

Victor Bazarov wrote:

[Hungarian-like notation]

this happens very rarely in practical applications. Dont remember when
happened to me.

Perhaps you change types seldom /because/ your naming convention makes
it hard?

Although to be honest, I don't seem to do a lot of type changes
myself, even though I'm not locked down by prefixes.

/Jorgen

 

[Öö Tiib]

For example with global integer you could use:

int g_nCounter;

He did ask about your policy with class prefixes that global integer
is totally different entity.

Just looking the name you know its global AND its an integer. Handy ... .

Yes. When you have several threads then you can just search your code-
base for "g_n" to find out all broken places that use mutable global
integer for something dim in multithreaded program.

If you put m_, that would mean a class memeber

I have seen code-base where several local variables were prefixed with
m_ and even one typedef'd type. So obviously not everybody taken into
team did understand wtf that m_ is about ... they put it here or there
just for a case. Without set coding policy that outright demands such
things and reviews that check if the policy has been followed it is
bloat of two characters.

 

[James Kanze]

Victor Bazarov wrote:
On 3/3/2011 9:27 AM, crea wrote:
Alf P. Steinbach /Usenet wrote:
* crea, on 03.03.2011 13:43:
Lets say we are programming a wheather data analysing and display
program (of course using VC!).
We have already classes:
- CChart, which draws wheather data
- CWheather, which contains wheather data and all the functions
regarding analysing data. So this data (it contains the data) can
be passed to CChart to draw it.
Presumably[1] the "C" signifies "Constant"?
No, it means "class" (CWheather = "class Wheather"). They are 2
normal classes...
Alf was teasing you (see his footnote). Microsoft's habit of putting
'C' in front of all their classes is surely contagious, isn't it?
yes, They use C. But I think its quite logical... C like class... This was
you know its a class type.

And what types with e.g. member functions and private data
aren't class types?
In fact, the Microsoft convention is used for functions in MFC,
it's a private prefix (MFC predates namespaces), used to avoid
the risk of name collisions with user classes (which, of course,
should never be prefixed with a C.) It's not a good

There was never a Microsoft prohibition on prefixing user classes with a
C

Microsoft never prohibited anything, as long as you were
spending money on their product. (Microsoft isn't alone in
this, of course.)

in fact the exact opposite is true: if you create a new project called
"foo" the application wizard will create such classes as CfooApp,
CfooDoc, CfooView and CMainFrame.

That's horrible. You mean that the Wizard encourages really bad
code.

 

[crea]

That's horrible. You mean that the Wizard encourages really bad
code.

So you guys dont use "C" in front of class names? I am totally used to it...
been using since 1996 ... we are speaking about VC++5 ...

It would be "wierd" not to use it...

 

[Victor Bazarov]

So you guys dont use "C" in front of class names?

Not if it's superfluous. For instance, if I have a class modeling a
group of lights, I call it LightGroup, not CLightGroup. OTOH if I have
a class modeling a list of arguments the system passes to a program, I
call it CommandLine. The latter sports the "C" as its first letter ("in
front"), but it's definitely not superfluous. I can swear I do not omit
'C' just for the sake of omitting it. *That* would be weird. Imagine
my class for arguments would be called 'ommandLine'... 8-O

I am totally used to it...
been using since 1996 ... we are speaking about VC++5 ...

It would be "wierd" not to use it...

Some folks are so used to wearing a hat, they wear one even when they
are in bed sleeping. To them it would be weird not to wear it...

V

 

[Paul]

I tend to use the Microsoft C class prefix convention for any classes that
derive from an MFC class; this means that most of my GUI (e.g. view) class
names are CCamelCase whilst all other (e.g. model/controller) class names
are lowercase_like_this.

Why don't you use both: class C_case{}?

I usually just capitalise first letter like this : class Case{}. I like the
capital first letter to easily see the difference in code between types and
names e.g:

Case case1; /*clear code*/
Case(); /*Obviously not a function call*/
do_something(); /*obvioulsy is a function call*/

I guess I can see why people are happy to stick with the CCase syntax
because its makes the code very readable. I think the extra C is a bit
overkill though , simply capitalising the first letter is fine for me.