Reputation: 2014
Teacher confused about MVC?
I have an assignment to create a game in java using MVC as a pattern. The thing is that stuff I read about MVC aren't really what the teacher is telling me.
What I read is that the Model are the information objects, they are manipulated by the controllers. So in a game the controller mutates the placement of the objects and check if there is any collision etc.
What my teacher told me is that I should put everything that is universal to the platform in the models and the controllers should only tell the model which input is given. That means the game loop will be in a model class, but also collision checks etc. So what I get from his story is that the View is the screen, the Controller is the unput handeler, and the Model is the rest.
Can someone point me in the right direction?
Upvotes: 6
Views: 219
Answers (2)
Reputation: 7193
Well you are describing a MVP pattern: you don't want your model to be view-related, so your view (screen) can't access directly your model. Most of the time, it results in cleaner code, but it depends on your usage: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter
In MVC, you can access model in the view, so you can make model objects which are more tight coupled (see databinding for instance) with your view (has some advantages too).
Putting most of the logic in the model instead of the controller is not related to MVC or MVP directly, it is about Domain Driven Design which is an important part of OOP: http://en.wikipedia.org/wiki/Domain-driven_design
It is a best practice for OOP, if your domain object (model) can answer questions about the data it contains, then it musts contain the implementation, don't go through Anemic Domain Model (which is quite popular today due to the hype of functionnal programming): http://www.martinfowler.com/bliki/AnemicDomainModel.html
Upvotes: 0
Reputation: 5075
There actually are multiple valid implementations of the MVC pattern to a given application. What fundamentally characterizes an application as an MVC application is that the developer(s) seperate functionalities into the three broad categories model, view and controller.
For the most part, the model contains an abstraction of the current state of the application and/or the underlying data. The view comprises everything that handles presentation. The controller typically is a middling instance between view and model and vice versa: e.g. if user input modifies the data model, the controller is ought to apply these changes (or void them if they are invalid); and the other way round, if a state in the model is present that is defined to result in a certain output to the view the controller will enforce this.
These are blurred lines however. The applicability of an MVC design typically is limited by the programming language you are using.
In other words, you have to improvise to some degree. Seperate functionalities as much as it is sensible but do not overdo it where it does not make sense.
A few resources:
Upvotes: 5