Re: Design help needed (model view controller)

In article <1148313993.960676.214460@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"BrianS" <Finster_Baby101@xxxxxxxxxxx> wrote:

I am trying to create a paint-like program in C++ for a class I am
taking. This is my first "big?" project for me. I started but my
design is too simplistic and it is becoming a nightmare. So I would
like to find a better approach and start over with a good design.
After doing some research I found the Model View Controller pattern and
I think this could be what I am looking for. I also found a variation
of this pattern called "Taskmaster" from the folks at objectmentor.com
http://www.objectmentor.com/resources/articles/taskmast.pdf

In taskmaster they create a simple "Line" class which is just basically
a definition of a line. They also have an abstract "GraphicObject"
with a draw method and then make a "GraphicLIne" that contains a Line
and can draw one on the screen. I like this design, but for my app I
am getting confused.

In my application I will also have to keep track of the pen width and
color. So I figure that I can add appropriate methods to GraphicObject
to take care of the pen and color. No problem so far.
However, I plan to keep a list or vector of objects that the user wants
drawn in the model, but that fact that it now has drawing information
like pen width and color and is in the model troubles me. Isn't that
breaking some of the decoupling rules? Pen width and color to me seem
to belong to the view, no? If I try to maintain a list of simple
objects (without pen width and color) in the model and another list in
the view (with width and color) that seems bad too. Either this is
duplicating my effort or I can see these lists possibly getting out of
sync. So now what?

It can sometimes be hard to determine what should be in the model and
what should be in the view, especially for a drawing program or game.

Maybe this will help... Imagine that you need to transmit a drawing from
one computer to be displayed on another. You want to minimize the amount
of data that gets transmitted, but at the same time, you need to fully
describe the picture. Anything that can reside in the receiving program
without having to be transmitted is part of the View, anything that must
be transmitted is part of the Model.

If I were to describe to you how to draw a picture of a house with some
crayons, it wouldn't be enough for me to say, "draw a line from here to
there." I would also have to tell you which crayon to use, and probably
I would have to tell you how thick to make the line. I am the Model, and
you are the View.


I also thought that this (array or vector or list) of objects (my
model?) could be used to repaint
the screen through the view when necessary. I hope this made some
sense. So what's the best way to go about this?

IMO, the View should not duplicate any of the information in the Model.
When it comes time to repaint, the View should again consult the Model
to figure out what to repaint and how. This ideal may need to be
sacrificed on the altar of efficiency sometimes, but don't do that until
you find you have to.
.

Relevant Pages

  • Re: Why return None?
    ... > That extend doesn't work for strings and tupples is irrelevant. ... If lists were being designed from scratch today, ... A "greenfield design", an entirely new language designed from scratch, ...
    (comp.lang.python)
  • Re: How would Mr. Stroustrup implement his solution to 12.7[2]
    ... >> pass a reference to the Window object to the Shape's draw(), ... > iterators supplied by each Shape object in order to get the Shape's shape; ... enough design, or even the best design, for a system with these limitations. ... > for parameters over const ints, but I thought he was doing that for some ...
    (comp.lang.cpp)
  • Re: When to use sub-values
    ... big objection was simply that it was aesthetically rude. ... The line item elements could be viewed as sub-values logically (eg the ... So, design with "line items" yes, with atomic attributes, no, not ... as Lists of Lists is to me the central strength (along with ...
    (comp.databases.pick)
  • Re: How did you complete this?
    ... grasp of the fundamentals of dbase design to ultimately save time by getting ... sightings and the various lists, and that as you say will warrant some ... the facility to record lists of species seen. ...
    (microsoft.public.access.formscoding)
  • Re: Abbreviation List Tables Design, aka OTLT
    ... access system control items. ... It is almost always dismissed as a terrible design by ... > Then code lists for everything with a "reasonable number of entries," ... > such as status codes, marital status, state codes, etc can all be in ...
    (comp.databases.pick)