Re: Is this a good class hierarchy for my project
On Mar 22, 5:09 pm, "crea" <n...@invalid.com> wrote:
Goran wrote:
Ah, OK then. But still, it looks like containment is better.
...
OK, I think I see what you mean. It's your analysis that's "producing"
these? If so, that's the classic MVC operation: model changes, so
views need to update. In light of MFC, that means calling
UpdateAllViews with "DifferentMark" or whateverr explained by means of
lHint and pHint.
I think the current best version with container is then:
class WeatherData {}
class WeatherDocument : public CDocument
{
WeatherData m_Data;
}
Then we have the Analyze classes:
class Analyze
{
WeatherDocument m_doc;
}
Then from Analyze we can do UpdateAllViews:
m_doc.UpdateAllViews(...);
to draw at certain point in the middle of Analyzing. This would go to Cha=
rt
view. Would this work and is this what you also meant?
Document is handled by the framework, so it's going to be difficult
for Analyze to contain the document. A reference to a document, yes.
Analyze should only exist while analysis is running (it seems to be a
function, or a function object at best, with a set of intermediary
results). In a classic MVC, Analyze would come from the controller,
and it would modify the model (document), which would cause view
update. Or at least that's how I see things.
When is the analysis running? Is it long? Given it's weather data, I
am guessing yes. So that's going to be run in the background? If so,
you have other important considerations (how to transfer change
notifications from background to UI).
Goran.