All geek questions in one place

Teacher got confused about MVC?

I have a task to create a game in java using MVC as a template. The fact is that the material I read about MVC is not really what the teacher tells me.

What I am reading is that the model is information objects, they are controlled by controllers. Therefore, in the game, the controller mutates the placement of objects and checks if there are any conflicts, etc.

What my teacher told me is that I should put everything that is universal for the platform in the models, and the controllers should indicate only the model whose input is given. This means that the game loop will be in the model class, but also checked for collisions, etc. So what I get from his story is that the view is the screen, the controller is the master descriptor, and the model is the rest.

Can someone point me in the right direction?

+6
source share
2 answers

There are actually several valid implementations of the MVC pattern for this application. What fundamentally characterizes the application as an MVC application is that the developer (s) shares functionality in three broad categories of model, view, and controller.

In most cases, the model contains an abstraction of the current state of the application and / or the underlying data. A view contains everything that processes a presentation. The controller is usually an intermediate instance between the view and the model and vice versa: for example, if user input changes the data model, the controller must apply these changes (or discard them if they are not valid); and vice versa, if there is a state in the model that is defined to obtain a certain result in the view, the controller will provide this.

These are blurry lines. The applicability of MVC design is usually limited to the programming language you use.

In other words, you need to improvise to some extent. Separate functions, as far as reasonable, but do not overdo it where it does not make sense.

Several resources:

+5
source

Well, you are describing an MVP pattern: you do not want your model to be associated with a view, so your view (screen) cannot directly get your model. In most cases, this leads to cleaner code, but it depends on your use: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter

In MVC, you can access the model in the view, so that you can make the model objects more rigid (see data binding, for example), with your view (also has some advantages).

The inclusion of most of the logic in the model instead of the controller is not directly related to MVC or MVP, we are talking about Domain Driven Design, which is an important part of OOP: http://en.wikipedia.org/wiki/Domain-driven_design

This is the best practice for OOP, if the domain object (model) can answer questions about the data contained in it, then it must contain an implementation, it does not go through the anemic domain model (which is quite popular today due to the hype of functional programming): http: / /www.martinfowler.com/bliki/AnemicDomainModel.html

0
source

Source: https://habr.com/ru/post/957726/

More articles:


All Articles