Design advice : How to add the UI ?

[Julien]

Hello everyone,

I'm programming a simple gaz particule simulator, (in C++) and I wonder what is the best way to link the UI with my other classes.
Here is my conception, any comments or advices are welcome :)

We simulate particules moving in a room.
The view should be able to show the particules moving in an openGl view, or to describe their position in text mode.

Here is what I have for now : (question below)

A data structure

Particule { Speed ; Position ; Mass };

A data structure

Room { Width ; Heigth ; Length };

A class Motion that has one logic method responsible for moving the particule for a given time :

Motion {
    void move( vector<Particule*> , Room* , Time dt );
};

A class Init that gives proper Positon and Speed to new particule :

Init {
    void init(Particule* , Room*);
};

Questions :

1) Should I give to each particule a view_component ?

My particule are of different kind (Neon, Argon, Silver, etc).
That changes nothing for the Motion part, but I would like to display them differently.
What's a good way to do this ? Should I give to each particule a view_component ? If so, does the motion class have to know ?
I also need somewhere to store the particules : if they have a part specific to their graphical representation, how could I instanciate them from the App and still be able to change the UI as a plug-in ?

2) Or something else ?

I tried a method :

void render(vector<Particule*> , Room*);

but once the type of a specific particule is lost I can't get it back (no RTTI).

Thank you for your advices :)

[Sebastian Gozin]

Sounds to me like the particle type or name should be part of it's attributes so you can use that to select an appropriate renderer.

[unclebob]

The view could be a visitor over the particles.  That way the particles don't need to know how to draw themselves, and yet the view will be polymorphic based on the particle type.  Each particle does not need it's own view; the view could be for the room; and the room view could create the visitor and then pass each particle to it.  The visitor would do the drawing.

[Julien]

Hello Sebastian, hello Uncle Bob,
Thank you for your answers !

I tried the visitor pattern, and I have a problem with something :

1) For the openGl view, I need to be able to attach the camera to a particule.
2) Some particules must leave a trace behind them (i.e. lines between their 10 last positions).
I should have mentioned it earlier !

I don't see how I could do it with a visitor pattern (or a switch).
I thought about creating a wrapper class, say ViewableParticule that has a physic component (Particule) and a graphic component. That way the Motion class don't know anything about the view. However that means that everytime we change the UI, we have to change all those wrapper classes...

Thanks for your help :)

Le jeudi 8 janvier 2015 15:18:40 UTC+1, unclebob a écrit :

The view could be a visitor over the particles.  That way the particles don't need to know how to draw themselves, and yet the view will be polymorphic based on the particle type.  Each particle does not need it's own view; the view could be for the room; and the room view could create the visitor and then pass each particle to it.  The visitor would do the drawing.

[Julien]

Hello, here is a new idea that I had yesterday :
What about using id instead of an object ?

I could have a Controller that tells the PhysicSystem to add a particule, and receive the physic_id of that new particule.
Then the Controller would tell the ViewSystem to add a particule, and receive the view_id of that new particule.
The controller makes the link between the two :

physic_motor.update(particule.physic_id);
view.redraw(particule.view_id);