I have a checkers/draughts game that uses the MVC pattern to structure the game.
Model - The game state number and position of pieces on the board.
View - handles user input, event handlers are here.
Controller - calculates the next move for the computer, changes in the model whos go it is etc.
The model is observable and the view observes the model.
The only thing is the model has a lot of fields that need to be observed by the view.
Whosgo, game type, pieces on the board etc. This are all either separate classes or enums themselves.
At the moment I have just the game class in the model as observable.
Should I have every member variable in the model observable as well?
Or could it be done by just having the game class(which contains all information about a game) as the only class that is observable.
This is the way I though it out.
The user will make a move, the controller will need to validate this move and then update the model appropiatly.
Then the controller would calculate the computers move and update the model.
I though the model was only for holding data and would only really have get and set methods.
The Controller's task is to mediate between Model and View(s). It should not contain business logic (in your case: Game logic).
Rules of a game are an integral part of the business model, and in MVC that belongs with the Model component.
By the way, your View is observing the Model. That makes your Controller a bit redundant.
The 'Overview' section in this Wikipedia article explains the main Controller duties.
You have choosen option 4b: " In others, the view is automatically notified by the model of changes in state (Observer) that require a screen update.", and you moved respnsibility of event ghandling from Controller to View.
The primary goal of the Model-View-Controller design pattern it to reduce coupling between an application (Model) and one or more presentation formats (View). The Model includes both business/domain logic and business/domain data.
The purpose of a Controller is to mediate and facilitate communication between the business objects (Model) and the presentation objects (View). Ideally, a single application (Model) should be easily able to support multiple views, e.g. HTML Browser, PDA, Cell Phone, Command-Line, Swing-based Desktop app, etc.
Generally, this pattern is best applied to large applications with hundreds of objects. For example, a Struts-based Controller typically consists of at leat 100 objects all working together. And yes it gets complicated.
Timmy, if you feel that what you have done above is too complicated, then try to think of ways to make it easier. If you can make it easier, that is good. However, keep in mind that your application is way too small and cannot reflect the benefits of the MVC pattern.
I think MVC is a good way to go for this project as it has a swing user interface now, but as the main point of the project involves getting the computer to play each other to make it improve its game.
This output could go to a database or a file. So I think having a swing view and a model is a good idea.
Putting the event handlers in a controller seem to make the project more compleciated than it should be.
So im going to keep them in the view and the controller will not do too much.
Its hard to decide which way to go as everybody has conflicting information which is valid in its own right, so im just trying what works at the moment.
Joined: Apr 16, 2008
Sounds good Timmy. Software design is a bit different than writing code. And there are typically many, many different ways to designing software applications. There never is a "right" way and a "wrong" way. There are shades or gradations which lean towards being better or worse than others. Moreover, human judgement plays a big role here in being able to navigate successfully. Some humans think more with their right-side of their brain and some humans think more with their left-side of their brain. And some, can switch back and forth for specific situations. These three ways of thinking are different and evident in the practice of software engineering. Ideally, you will want to work with others that think like you and be able to understand others from the other side.
In contrast, when you are writing source code, a compiler is checking code and there are "right" and "wrong" ways to write code statements. You either write is "correctly" or it does not work.