Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Class design issue

Reply
Thread Tools

Class design issue

 
 
crea
Guest
Posts: n/a
 
      03-03-2011
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.



 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      03-03-2011
On 3/3/2011 7:43 AM, crea wrote:
> 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
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
 
 
 
crea
Guest
Posts: n/a
 
      03-03-2011
Victor Bazarov wrote:
> Also, post to 'comp.object' to learn more about OOD.
>
> V


I continue there..


 
Reply With Quote
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      03-03-2011
* 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.

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
crea
Guest
Posts: n/a
 
      03-03-2011
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...


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      03-03-2011
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
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
crea
Guest
Posts: n/a
 
      03-03-2011
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.


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      03-03-2011
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 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
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
crea
Guest
Posts: n/a
 
      03-03-2011
Victor Bazarov wrote:
> 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.

> 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


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      03-03-2011
On 3/3/2011 12:14 PM, crea wrote:
> Victor Bazarov wrote:
>> 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.
> [..]


"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
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
CFP - Journal of Systems Architecture, Embedded Software Design(Elsevier), Special Issue on Hardware/Software Co-Design Juan A. Gomez-Pulido VHDL 0 08-24-2009 02:11 PM
2nd. CFP - Journal of Systems Architecture - Embedded Software Design(Elsevier) - Special Issue on HARDWARE/SOFTWARE CO-DESIGN Juan A. Gomez-Pulido VHDL 0 05-24-2009 03:14 PM
class design vs. db design John_Woo Java 2 12-19-2006 08:27 PM
Nested Class, Member Class, Inner Class, Local Class, Anonymous Class E11 Java 1 10-12-2005 03:34 PM
Class design/design pattern resources TomTom MCSD 2 10-09-2004 07:38 AM



Advertisments