Class design issue

[Paul]

On 3/3/2011 10:26 AM, crea wrote:
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.

Eh?
int n_x;
You cannot change the type of n_x .

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

Pah you know he means they represent decimals.

 

[Paul]

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?

The C++ language makes it impossible.

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.

How do you change the type of a variable?

 

[Öö Tiib]

Eh?
int n_x;
You cannot change the type of n_x .

Certainly you can. It goes so: go to start of line, press del 3 times
and then type "char".
It will look like that:

1) int n_x;
2) nt n_x;
3) t n_x;
4) n_x;
5) c n_x;
6) ch n_x;
7) cha n_x;
8) char n_x;

See ... variable n_x's type changed from int to char.

 

[Paul]

Eh?
int n_x;
You cannot change the type of n_x .

Certainly you can. It goes so: go to start of line, press del 3 times
and then type "char".
It will look like that:

1) int n_x;
2) nt n_x;
3) t n_x;
4) n_x;
5) c n_x;
6) ch n_x;
7) cha n_x;
8) char n_x;

See ... variable n_x's type changed from int to char.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

LOL
500 pages of code, and you change a variable type like this, your gonna have
big problems changing every function that uses it, overloading them, or
templating.
Changing the variable name with a quick search and replace is gonna be the
least of your worries.

 

[Bo Persson]

Certainly you can. It goes so: go to start of line, press del 3
times and then type "char".
It will look like that:

1) int n_x;
2) nt n_x;
3) t n_x;
4) n_x;
5) c n_x;
6) ch n_x;
7) cha n_x;
8) char n_x;

See ... variable n_x's type changed from int to char.

))

The problem here isn't the n, but the x. What the heck is an x?


Bo Persson

 

[Nick Keighley]

I continue there..

last time I looked comp.object was pretty dead

 

[Nick Keighley]

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.

I'm not sure what your classes do. But I think I'd add a WeatherView
class and leave your Weather class (I refuse to go the way of the
hungarian) to hold and analyse data. The WeatherView would be in
charge of drawing pictures and might well change as different
standards are used for different charts.

I might add a Drawable which both Chart and WeatherView derive from.

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

};

I can see that WeatherChart IS-A Chart but I don't see that
WeatherChart IS-A a Weather.

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

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

};

or maybe inherit from Chart and embed Wheather. With my Drawable class
I think I'd go with your option 2.

(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)

not sure SummerWeather makes sense as a class. It looks more like an
instance of EarthWeather.

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

I'd do it differently.

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.

I don't think Weather *should* be changing. Its data will change but
I'd expect its interface to be pretty damn stable. Weather now
contains the same stuff as it did 20 years ago.