Question about designing with Model-View-Controller
Author
Hi guys,
I'm putting together a Tetris game, but I'm doing it mostly to practice implementing design patterns.
I have a question about whether this is a "bad design practice" :
Right now I have my tetrinos made up of 4 Squares, and I'm going to pass to have a function that returns these so the View / Renderer part of the program can draw them based on their positions.
But... this seems sloppy somehow. It breaks information hiding / encapsulation when the Tetris piece just passes out its Squares...
Do you agree?
Another way I can think of doing it is to have the Squares draw themselves.
But that also seems ... well, not very flexible. I'd rather the rendering part of the game is separate from the data/state part of it.
I know this is probably over the top for a simple Tetris game, but I'm doing it more for design patterns and OO-design practice than anything.
Any advice?
It's not breaking information hiding if they tell the rendering system "my renderable part is made up of these four square shapes" rather than making available 'Square', the object that has game logic and so on. Does that help?
Yeah, you can separate them better by following "programming to interface", something very basic could look like:
interface Renderable { getVertices() getIndices() getMaterial()}class Square implements Renderable { some data some other data .... getMaterial() { .... } ....}class Controller { .... render() { view.enqueue(model.getRenderableList()) view.render() } ....}
Just in case you are using 3D acceleration and wanted to render your squares as sets of indexed triangles (using 4 coordinates instead of 6 per square, not really saving much here with Tetris). You can safely ignore it, the idea is that you expose an interface from which you can get only the data needed for rendering - The renderer does not deal with game "squares", but with renderable objects, pretty much as hymerman already said.
I imagine it holds indicies for referencing verts for the polygons (because polygons often share the same verts).
Author
Alrighty, I think I get it.
I'm just using SDL, so I guess I can stick to planar coordinates for now.
(Or maybe just use 0 for the third coordinate? Might keep it more flexible for later?)
I've barely done anything with OpenGL yet, so I'm not too sure how it renders based on the vertices.
The amount I still have to learn is daunting, lol
Author
I ran into a snag: Implementing MVC in Java o_O
I've got the Model part down. But if I understand correctly, the Controller should handle the input, right? So far in my Java applications, I've always stuck some kind of EventListener on GUI components. That would mean that the View receives the user input... does this still work?
I can't have the View know anything about the Controller, so it can't pass the input to it... But maybe I can have it keep track of input events, and then the Controller can call a View function to retrieve them?
Or maybe I can use an Observer pattern to notify the Controller?
What do you think?
Can I create a valid MVC pattern in Java?
Strict adherence to MVC may or may not be reasonable, but in this case I think it won't hurt. As you already surmised yourself, the Observer pattern can help you implement communication from View to Controller in a decoupled fashion. Polling would also work, if you wanted to process them all at once - depends on how you wanna handle it.
Quote:Original post by meteorstorm42
I've got the Model part down. But if I understand correctly, the Controller should handle the input, right? So far in my Java applications, I've always stuck some kind of EventListener on GUI components. That would mean that the View receives the user input... does this still work?
I can't have the View know anything about the Controller, so it can't pass the input to it... But maybe I can have it keep track of input events, and then the Controller can call a View function to retrieve them?
Or maybe I can use an Observer pattern to notify the Controller?
Basically, you seem to be worried about the View/Controller separation (pulling the Model apart from the other two is generally straightforward). Don't worry about it too much; in a sense, the whole "Listener" thing is already acheiving that separation.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
