Model View Controller - please clarify

[hugo.elias]

Hi all,
I hope nobody minds me posting this question to this group, but I
couldn't find any group closer to the Subject.

Can anyone clear up where you draw the lines when dividing up an
application into Model, View and Controller parts?

For example: I have some classes:

class FlatWorld;
class Shape;
class BlobbyShape; // inherits from Shape
class StringyShape; // inherits from Shape
class GassyShape; // inherits from Shape
And my application is split thus:

Model:
The Shapes. And Flatworld which contains a vector<Shape>

View:
Class which gets information from Flatworld, and renders the Shapes.

Controller:
Class which interprets mouse clicks/drags and tells the Shapes to
move or change shape.
The other important thing I have learned is to do things Once And Only
Once (OAOO). The problem is that the MVC concept seems to break the
OAOO principle, because two classes (perhaps written by two different
people) need to know enough about the Shapes to be able to render them.
For example the GassyShape is rendered in a totally different way to
the StringyShape. Also, there are totally different methods for
manipulating the Shapes.

What happens when someone writes a new kind of Shape? The author of
the View has to be contacted and taught how to read the information and
render the shape, and he must edit his code. Ditto the Controller.

Wouldn't it be better to integrate the Controller and View into the
Model?

For example:
class Shape
{
virtual void Render(Surface *S);
virtual void Click(Point P);
virtual void Drag(Point P);
virtual void Release(Point P);
};

Now, new Shapes can be written at any time, and they take care of
themselves, simply being told when/where to render, and any mouse
actions that come their way.
I have Googled for this a lot, and read the C2 Wiki, but I still can't
find a decent resolution to this. Can anyone offer any advice?
Many thanks in advance.

Hugo Elias

[Victor Bazarov]

hu********@virgin.net wrote:

Hi all,
I hope nobody minds me posting this question to this group, but I
couldn't find any group closer to the Subject.

Can anyone clear up where you draw the lines when dividing up an
application into Model, View and Controller parts?
[...]

I actually consider news:comp.object to be closer in topic to this
instead of any language newsgroup. But that's just MO.

[Rolf Magnus]

hu********@virgin.net wrote:

Hi all,
I hope nobody minds me posting this question to this group, but I
couldn't find any group closer to the Subject.
comp.object would be my guess. It's more a gerneal problem of object
oriented programming rather than specific to C++.
The other important thing I have learned is to do things Once And Only
Once (OAOO). The problem is that the MVC concept seems to break the
OAOO principle, because two classes (perhaps written by two different
people) need to know enough about the Shapes to be able to render them.
For example the GassyShape is rendered in a totally different way to
the StringyShape. Also, there are totally different methods for
manipulating the Shapes.

What happens when someone writes a new kind of Shape? The author of
the View has to be contacted and taught how to read the information and
render the shape, and he must edit his code. Ditto the Controller.

Wouldn't it be better to integrate the Controller and View into the
Model?

I think you missed the whole point of the MVC concept. The idea is that you
can vary the view and the controller independant of the model and even have
multiple views at the same time fore one model. So you can have one view
that shows you a graphical representation and another one that shows you a
textual list of the object names and properties. Or just simply two
graphical views of the same type, but each showing a different part of the
model.

[Adios]

Victor Bazarov wrote:

hu********@virgin.net wrote:

Hi all,
I hope nobody minds me posting this question to this group, but I
couldn't find any group closer to the Subject.

Can anyone clear up where you draw the lines when dividing up an
application into Model, View and Controller parts?
[...]

I actually consider news:comp.object to be closer in topic to this
instead of any language newsgroup. But that's just MO.

Well there's a surprise, Dull Vic moans again...

[hugo.elias]

Yes, I do realise that that's one of the benefits of MVC, so, for
example, I could print the shapes to paper, rather than rendering them
to the screen.

But even in this case, I think the same question applies. Surely, if
the application is divided this way, then changes to the model have to
affect the view and the controller also?

Integrating the rendering code into the model still lets me have
multiple views of the model at the same time. For example I could just
tell my models to render themselves to different places:

Shape.Render(dc1, RenderSettings1);
Shape.Render(dc2, RenderSettings2);
It seems to me that MVC depends how much is likely to change. If the
model (code) changes often, and new Shapes appear and require different
access functions, requiring constant updates to the view (code), then
it hardly seems worth having separate M,V,C.

But if you can have a totally consistent set of member functions for
all the Shapes, then no changes are ever needed to the view, and the
MVC concept does help.
I can see both sides of the argument. Two sensible ways of dividing
the application are pulling in different directions. Is there anyone
who has encountered a problem like this, and can shed any light?

Many thanks again, and sorry for the slightly OT posting. I'll aim
for comp.object next time.

Hugo Elias

[Howard]

<hu********@virgin.net> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

Yes, I do realise that that's one of the benefits of MVC, so, for
example, I could print the shapes to paper, rather than rendering them
to the screen.

But even in this case, I think the same question applies. Surely, if
the application is divided this way, then changes to the model have to
affect the view and the controller also?

Integrating the rendering code into the model still lets me have
multiple views of the model at the same time. For example I could just
tell my models to render themselves to different places:

Shape.Render(dc1, RenderSettings1);
Shape.Render(dc2, RenderSettings2);
It seems to me that MVC depends how much is likely to change. If the
model (code) changes often, and new Shapes appear and require different
access functions, requiring constant updates to the view (code), then
it hardly seems worth having separate M,V,C.

But if you can have a totally consistent set of member functions for
all the Shapes, then no changes are ever needed to the view, and the
MVC concept does help.
I can see both sides of the argument. Two sensible ways of dividing
the application are pulling in different directions. Is there anyone
who has encountered a problem like this, and can shed any light?

Many thanks again, and sorry for the slightly OT posting. I'll aim
for comp.object next time.

Hugo Elias

I find that hard-and-fast rules tend to be so inflexible as to render them
useless in many practical applications.

I do a lot of work in both the Mac and Windows environment, and the handling
of mouse events and keyboard entry and files are different between the two.
But in both platforms, my mouse events and my drawing itself need to be
handled by a class that's appropriate to the platform.

For example, on Windows, I've got a window class that's handling all mouse
events, and it passes on ones that are of interest to what I guess you'd
call a controller class. That controller class uses a pointer to the window
that called it (and the "device context" for that window) in order to place
the graphical objects where I want them. I pass that "graphical context"
information down to the individual graphical objects (shapes), and let them
draw themselves. (I pass this info in a small class of my own design whose
sole purpose is to hide the details of that graphical context information,
making my interfaces consistent across platforms.)

My "controller" class certainly knows about each of the types of objects
that it might contain, although that's really only needed because it has to
create them (and store them as a pointer to the base class type). My
"view", or window class, doesn't know about the shapes at all; it only knows
about the controller class. And my shapes simply use virtual functions to
draw, copy, hide, move or whatever, using the "graphical context"
information. (This same type of information is passed to different
functions for streaming internal info, or for rendering to a "printer"
context.

Using this type of design, I can write a different view class to support
each platform and different (but similar) shape classes to support each
platform, and the controller really only needs minor adjustments to handle
passing different types of handles or pointers to the view, based on what
the platform requires (e.g., an HDC, HANDLE, WIndowPtr, etc.).

-Howard

[Vince]

Howard a écrit :

<hu********@virgin.net> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

Yes, I do realise that that's one of the benefits of MVC, so, for
example, I could print the shapes to paper, rather than rendering them
to the screen.

But even in this case, I think the same question applies. Surely, if
the application is divided this way, then changes to the model have to
affect the view and the controller also?

Integrating the rendering code into the model still lets me have
multiple views of the model at the same time. For example I could just
tell my models to render themselves to different places:

Shape.Render(dc1, RenderSettings1);
Shape.Render(dc2, RenderSettings2);
It seems to me that MVC depends how much is likely to change. If the
model (code) changes often, and new Shapes appear and require different
access functions, requiring constant updates to the view (code), then
it hardly seems worth having separate M,V,C.

But if you can have a totally consistent set of member functions for
all the Shapes, then no changes are ever needed to the view, and the
MVC concept does help.
I can see both sides of the argument. Two sensible ways of dividing
the application are pulling in different directions. Is there anyone
who has encountered a problem like this, and can shed any light?

Many thanks again, and sorry for the slightly OT posting. I'll aim
for comp.object next time.

Hugo Elias

I find that hard-and-fast rules tend to be so inflexible as to render them
useless in many practical applications.

I do a lot of work in both the Mac and Windows environment, and the handling
of mouse events and keyboard entry and files are different between the two.
But in both platforms, my mouse events and my drawing itself need to be
handled by a class that's appropriate to the platform.

For example, on Windows, I've got a window class that's handling all mouse
events, and it passes on ones that are of interest to what I guess you'd
call a controller class. That controller class uses a pointer to the window
that called it (and the "device context" for that window) in order to place
the graphical objects where I want them. I pass that "graphical context"
information down to the individual graphical objects (shapes), and let them
draw themselves. (I pass this info in a small class of my own design whose
sole purpose is to hide the details of that graphical context information,
making my interfaces consistent across platforms.)

My "controller" class certainly knows about each of the types of objects
that it might contain, although that's really only needed because it has to
create them (and store them as a pointer to the base class type). My
"view", or window class, doesn't know about the shapes at all; it only knows
about the controller class. And my shapes simply use virtual functions to
draw, copy, hide, move or whatever, using the "graphical context"
information. (This same type of information is passed to different
functions for streaming internal info, or for rendering to a "printer"
context.

Using this type of design, I can write a different view class to support
each platform and different (but similar) shape classes to support each
platform, and the controller really only needs minor adjustments to handle
passing different types of handles or pointers to the view, based on what
the platform requires (e.g., an HDC, HANDLE, WIndowPtr, etc.).

-Howard

www.wxwindows.org

[Thomas Maier-Komor]

hu********@virgin.net wrote:

Hi all,
I hope nobody minds me posting this question to this group, but I
couldn't find any group closer to the Subject.

Can anyone clear up where you draw the lines when dividing up an
application into Model, View and Controller parts?

For example: I have some classes:

class FlatWorld;
class Shape;
class BlobbyShape; // inherits from Shape
class StringyShape; // inherits from Shape
class GassyShape; // inherits from Shape
And my application is split thus:

Model:
The Shapes. And Flatworld which contains a vector<Shape>

View:
Class which gets information from Flatworld, and renders the Shapes.

Controller:
Class which interprets mouse clicks/drags and tells the Shapes to
move or change shape.
The other important thing I have learned is to do things Once And Only
Once (OAOO). The problem is that the MVC concept seems to break the
OAOO principle, because two classes (perhaps written by two different
people) need to know enough about the Shapes to be able to render them.
For example the GassyShape is rendered in a totally different way to
the StringyShape. Also, there are totally different methods for
manipulating the Shapes.

What happens when someone writes a new kind of Shape? The author of
the View has to be contacted and taught how to read the information and
render the shape, and he must edit his code. Ditto the Controller.

Wouldn't it be better to integrate the Controller and View into the
Model?

For example:
class Shape
{
virtual void Render(Surface *S);
virtual void Click(Point P);
virtual void Drag(Point P);
virtual void Release(Point P);
};

Now, new Shapes can be written at any time, and they take care of
themselves, simply being told when/where to render, and any mouse
actions that come their way.
I have Googled for this a lot, and read the C2 Wiki, but I still can't
find a decent resolution to this. Can anyone offer any advice?
Many thanks in advance.

Hugo Elias

I think you cannot find a decent solution, because you want to do a two
way dispatching inheritance scheme. This is not impossible to do in C++,
but you can do it numerous different ways - each with its own advantages
and disadvantages.

Maybe you would like to look at the different patterns that exist (e.g.
in Gamma's pattern book). But I think the problem you are having is far
too generic to propose a good solution...

Good Luck,

Tom