Re: Is this a good class hierarchy for my project
Goran wrote:
On Mar 21, 6:25 pm, "crea" <n...@invalid.com> wrote:
// 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.
USA weather data is set this way:
WeatherData usa_data;
USAWeatherAnalysis usa;
....
usa.SetData(usa_data);
(But I see, below, that you equate Weather with
WeatherAnalysis, so I don't quite know what to make of this).
The idea is that there is whether data for eatch country. But there is
*also* a different set of analyze functions for eatch country. So eatch
country has its own "system" to analyze the data. The different data per
country is not really the main point but rather the different systems per
country.
DrawDifferentMark seems to be UI-related. That's UI, not "analysis",
and so, it's suspect (you seem to be violating "single responsibility
rule").
Yes true. How about changing the name something like: "DifferentMark" so
then the receiver of the function can deside what to do (like draw)?
// class for USA weather
class USAWeatherAnalysis : public WeatherAnalysis
{
...}
// data drawing
// CView is a windows class in Microsoft C++ MFC foundation classes
to draw 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?
No. This is the second parent for USAWeatherAnalysisView (see below). The
aim is to store the address of the WeatherAnalysis data member (m_Data) to
m_pData so that the Chart can use this pointer to get hold of the data and
draw it. So we will set basically m_pData = &m_Data somewhere...
...}
// Then finally the class which hold everything together and links
data to windows view
class USAWeatherAnalysisView : public ChartView, public
USAWeatherAnalysis {
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?
As I asked before, can this be solved by just chaning the name to
"DifferentMark"? This way the name does not relate anymore to drawing.
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
version, 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 we 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 ;-)
In my situation the data does not really change... but its rather that the
Analyze-functions must communicate with the drawing side of the program and
vice verse.
So there is Data, different analyze/system functions (different set for
eatch country) and drawing the data on Chart. I was thinking that the Data
goes inside the Analyze class and then this Analyze -class could communicate
with drawing class via somekind of link class (USAWeatherAnalysisView in my
example).