thomasahle / TrinityProject

A mindblowing trainbased game for entire family
http://thomasahle.github.com/TrinityProject/
GNU General Public License v3.0
8 stars 3 forks source link

Model View separation #55

Closed MattPellegrini closed 12 years ago

MattPellegrini commented 12 years ago

This is a big one.

So I think (and fell free to correct anything here) that most of the UImodel package is the "model" and that all the components should have an accept(ComponentPainter painter) method that takes a Painter which belongs in the VIEW.

the method would be something like

accept(ComponentPainter p){

//draw the component if it has changed
p.visit(this);

//draw the trains
for(t: currentTrains){
    t.accept(p.getTrainPainter)
}

}

and ComponentPainter has a method visit(v) for all component types v and a TrainPainter tp, returned by the getTrainPainterMethod.

getTrainPainter would have a method visit(t) for all types of train t.

If people agree with this, or can correct me, I'll get working on this. It's quite a major change, but we should try to make our code as tidy as possible before continuing. It'll help in the long run.

thomasahle commented 12 years ago

I do agree that getting the painting further away from the painting would be great. And for the trains it might not even be too hard to do. Just remember to keep the door open for animated trains.

But in the components there is an extreamly tight bound between the visual and the semantic. To a degree where the visual nearly is the semantic. Think about sep (which I think should stand as an example for the three other components in the future), or think about the fade/cut in/out of the black boxes. I really don't see MV make sense for Components.

There are already some static drawing classes. We might be able to get rid of some of them, or make more.

EdShaw commented 12 years ago

Yeah, given that the model heavily depends on parts of the view (particularly timing and sizes), I'm not sure a meaningful separation could exist.