Re: Is this a good class hierarchy for my project
On Mar 21, 6:25 pm, "crea" <n...@invalid.com> wrote:
(this is also in comp.object group, but because it includes C++ and MFC c=
ode
also I put it here as well)
Lets say I have a weather data application to design. I have data and the=
n I
will draw it on windows.
This is how I was thinking to implement it:
Base-Classes: Data, Chart (to draw data on window), DataAnalysis (include=
s
all functions to analyze the data and create corresponding values to draw
info on chart)
Then we can inherit different weathers from these, like "Finnish weather"=
,
"USA weather", "Moon weather", "globe weather" etc.
This looks suspect to me. There's a lot of countries out there. I
would guess that you should extract country-specific functionality out
of the weather and use composition to achieve same functionality. In
general, "prefer containment to inheritance".
class CountryWeatherHelper
{
string Name();
};
class WeatherData
{
WeatherData(CountryWeatherHelper country)
// etc.
};
So the final result/class hierarchy would look like this (my question bel=
ow
them) for USA Weather (for example):
// Data
class WeatherData
{
...}
// classes for analysing data
class WeatherAnalysis
{
protected:
WeatherData m_Data; // data to analyze
void SetData(...);
WeatherData& GetData();
void DoSpecialAnalyze();
virtual void DrawDifferentMark();
...}
You hold m_Data by value, but you speak of having weather data per
country. If so, you can't make base class WeatherAnalysis to hold e.g.
USAWeather. (But I see, below, that you equate Weather with
WeatherAnalysis, so I don't quite know what to make of this).
DrawDifferentMark seems to be UI-related. That's UI, not "analysis",
and so, it's suspect (you seem to be violating "single responsibility
rule").
// class for USA weather
class USAWeatherAnalysis : public WeatherAnalysis
{
...}
// data drawing
// CView is a windows class in Microsoft C++ MFC foundation classes to dr=
aw
to windows
class ChartView : public CView
{
private:
WeatherData* m_pData; // a pointer to data to draw
protected:
virtual void DrawDifferentMark(int i);
public:
void SetWeatherData(WeatherData* pData) { m_pData=pData; }
Shouldn't it be WeatherAnalysis there?
...}
// Then finally the class which hold everything together and links data t=
o
windows view
class USAWeatherAnalysisView : public ChartView, public USAWeatherAnalysi=
s
{
public:
void ReadUSAWeatherDataFromFile();
virtual void DrawDifferentMark();
}
Now we can read and set the data:
void USAWeatherAnalysisView ::ReadUSAWeatherDataFromFile()
{
// reading data from file to WeatherData object
WeatherData data;
...
// Then storing the data to WeatherData m_Data -member:
SetData(data);
//Then passing pointer of this data to the other parent class ChartView:
SetWeatherData(&GetData());
}
Now lets say we analyze data on WeatherAnalysis:
void WeatherAnalysis::DoSpecialAnalyze()
{
for(eath data-item)
{
if(data item is different than other items)
DrawDifferentMark(item);
....
}
}
So we have a virtual function DrawDifferentMark in WeatherAnalysis:
class WeatherAnalysis
{
...
virtual void DrawDifferentMark(int item);.
...
This, IMO, is a bad idea. I think you should look upon MVC and related
patterns. You are putting UI-related artifacts into your "data", and
that works for one type of UI. That's a clear-cut viloation of single
responsability principle and you should not do it. If tomorrow you get
a different type of a view (e.g. textual), will you add PrintLine(int
line) to your WeatherAnalysis?
MVC prescribes that each view knows the model (WeatherData, or
Analysis) and draws the way it wants.
}
When DrawDifferentMark is called it goes to USAWeatherAnalysisView ver=
sion,
and from there we can call the corresponding drawing class method:
void USAWeatherAnalysisView ::DrawDifferentMark(int item)
{
ChartView::DrawDifferentMark(item);
}
So item pass route is: WeatherAnalysis -> USAWeatherAnalysisView ->
ChartView
Is this a good way to implement the communication between data and
view/drawing windows? This way also if something happens in windows and w=
e
want to communicate that to data classes (or analyzing classes), then we =
can
similarly create a virtual function in Chart class and route it via
USAWeatherAnalysisView to analysis/data classes
(ChartView ->USAWeatherAnalysisView-> WeatherAnalysis ).
A good and largely accepted way is Model-View-Controller. MFC has a
thing called document-view framework, who is similar (in general,
controller is kinda missing, but that's IMO quite acceptable in
context of MFC). According to (my understanding of) doc/view, MVC, and
your question, when "something happens in windows", it's two things:
* data changed (due to user action, due to data arrival from some
other "controlling force", e.g. Automation...); if so, changes go to
the document, and document uses UpdateAllViews to inform views.
UpdateAllViews walks views into the document and each view is
responsible for "parsing" the notification (lHint, pHint) and updating
itself. pSender param is the view where change originated from (if
any), and that view needs no updating, as he already knows what
happened and consequently, knows how to update.
* viewing options changed (e.g. user choose different color for some
UI artifact). That's something not really related to the document
(model), but it's still possible that it will become part of the
document (to show stuff in the same way between runs), and so,
UpdateAllViews stays. If not, if it's completely transitory, then a
mechanism of your own choosing is possibly the best option.
IOW, I say, study MVC and Doc/View and apply it ;-)
Goran.