Question

I was wondering whether the use of a decorator pattern is good in case I want my model (“M part” of MVC) to raise Exceptions depending on their origin. I explain myself.

I have a class called Game which is a part of the Model. I have two Views : a GUI and a command line. I want my model to raise an Exception for command line view when the user enters a character instead of a number (for example). Of course I don’t want this Exception to be handled by the model as it “belongs” to the command line and not to the Model itself.

To encapsulate those two different behaviors, I plan to decorate the Game class with two classes : CommandLineGame and GUIGame which have only one attribute : Game and handle their own kind of Exception. Is it a good idea ? Is there a better one ? The problem of such a solution is that every model class raising Exception depending on its origin has to be decorated…

Answer 1

What you are describing in the example is “input validation”. Strictly speaking*, this belongs in the Controller (“C Part”) of MVC.

The separation of concerns for MVC decomposes as follows:

• View is there to 1) present a UI for the user to evaluate the state of the program (Also, what your program looks like visually) and 2) to receive the user’s expression of intent (receive raw instructions on what they may want to do)
• Controller is the actual interpreter of these “actions” or “intentions” from the user. It decides what it means for a user to click a particular button and what to call in your model. It decides whether a particular input actually makes sense given context from the UI (and in some case from the model).
• Model should be View/Controller agnostic (Meaning the model should have no knowledge of the View/Controller). It should only be about the internal representation of what you are trying to “model”. The advantage of doing it this way: you can have many different UIs, or change your existing UIs without affecting the model.

Overall, the idea is to lower coupling and increase cohesion.

I hope that makes sense =)

Depending on the language / framework, the lines between MVC components get blurred a bit. Some idioms will lump most of Controller into the View, but the encapsulation of logic should stay relatively similar.

*In practice, for defensive programming, input validation is done twice for mutual suspicion: they are broken down into client-side mediation and server-side mediation:

• In this case, the Model part should handle the “server-side” mediation: it should check that the arguments passed to its functions actually make sense before proceeding.
• Similarly, the Controller/View part should check the input as part of “client-side” mediation, so that it can warn the user right away, without passing it back to the model, and then eventually back to the view.