0

I cant find a clear answer of my question.

In MVC, all is pretty divided in model, view and controller. So usually i'll create a controller object which holds instances of the model and the view. Model and view don't know anything from each other so that they have to communicate over the controller.

For example when i write my code for model of a game, there are classes like the "GameBoard" which usually holds an object container for objects of type "Tile"... "Player" or "Brick" can be an inherited class of "Tile".

For example on start there have to be some bricks for first level, so i have to initialize it in some place, i usually did that in the constructor of the GameBoard.

Is it generally a good practice to tell the "GameBoard"-Constructor which objects it should hold?

I am asking because I read something about the "single responsibility principle" ... so should the model only be the model (and nothing else) and don't care about initialization of itself?

Or is this "initialization" a task for the controller? When yes, should i divide one controller into multiple controllers which take care of its "single responsibility" ? Or is one controller enough between model and view?

Thanks

Don Joe
  • 25
  • 2

1 Answers1

0

In MVC, all is pretty divided in model, view and controller. So usually i'll create a controller object which holds instances of the model and the view. Model and view don't know anything from each other so that they have to communicate over the controller.

I'm not sure what you mean by this. I would not say that the model and the view interact of the controller, they actually never meet here. The model and the view communicate inside of the view.

For example when i write my code for model of a game, there are classes like the "GameBoard" which usually holds an object container for objects of type "Tile"... "Player" or "Brick" can be an inherited class of "Tile".

For example on start there have to be some bricks for first level, so i have to initialize it in some place, i usually did that in the constructor of the GameBoard.

Is it generally a good practice to tell the "GameBoard"-Constructor which objects it should hold?

Yes, that is exactly it. It is good practice to only allow a non-model object to receive values inside of a constructor. If you would like to take this practice seriously, you should add:

private set;

Onto the classes properties to make them immutable. This will limit your ability to modify this object to the constructor and the constructor only.

I am asking because I read something about the "single responsibility principle" ... so should the model only be the model (and nothing else) and don't care about initialization of itself?

The model should have much less strict rules about how data is stored within it. You can, for readability, add different constructors to allow you to populate the model on one line but it is not necessary.

Or is this "initialization" a task for the controller? When yes, should i divide one controller into multiple controllers which take care of its "single responsibility" ? Or is one controller enough between model and view?

Yes, the controller's only job should be to communicate with the view. The view needs data, so the controller will populate the model, and communicate that to and from the view. This should be all that it is doing.

A controller should only have one responsibility but that does not necessarily mean that it only does one or two things. It's up to the programmer's discretion on what the scope of their controller should be.

I hope this was helpful to you.

JPG
  • 145
  • 9