I'm very confused. I can't even begin to understand how MVC would be implemented outside of web development. This might seem like too general a question, but how would one apply MVC. I have the following general questions:

  1. Are M, V, and C all meant to be one class each, or many. If many, how would that work.

  2. Most classes I've made previously have had their data inside them, not in a separate class. How would this work with MVC?

1) For instance, lets say you have a class where you take care of a virtual dog. I would think that you would make a Dog class with, for example, a "bark" command that would play a sound along with a name variable and a coat_color variable. I know this is very simple, but how would this fit inside MVC? It seems that you would end up with MC and V, where the information (model) AND the controls were in the Dog class, which would maybe access swing, or whatever library, to update the view.

2) Or, what about a program like sims (simplified version) where each person would have their own information... would you put all that info in another class?

Sorry if these are all based on giant misconceptions, but I'm pretty confused. Right now I'm using Java, if that matters for MVC...


You're a little all over the map there, perhaps getting ahead of yourself thinking about video games and dogs and what not. The easiest way to think of MVC is to think of the responsibilities of the things in the acronyms. At its core level, each of the components answers a question:

  • Model: "What should we show the user?"
  • View: "How should we show it to the user (what will it look like)?"
  • Controller: "How do I figure out which models and views to show the user?"

So, I'd suggest digesting that a bit and perhaps focusing your questions a little. MVC is a "presentation pattern," meaning that it's not the basis for your entire application nor is it a philosophy or a universal approach to software development. All it really gives you is a way to separate the responsibilities involved in presenting information to your users. In this sense, you can use it on the web or the desktop or anywhere that you show things to users.

| improve this answer | |
  • +1 for the "component:question" dictionary. Succinct and clarifying. – radarbob Mar 21 '13 at 16:40

Heres something to think about. You used the example of a Dog class. then you ask yourself - what do dogs do? well they "bark". so lets make a method to Bark.

so then you have your Dog controller, and you put a Bark method in it. and then maybe you put specific things about Barking - the loudness, the tone, etc in a Bark Model.

and then you create methods for other actions like Walk and Eat and put them in your controller. and everything is working great and looks very logical.

But next your customer wants your dog to "whine" -- while begging. should you create a whine method? should you create a begging method and put something in about whining in there?

The problem was in the very first method we made. when we made a method called Bark, we set ourselves up to have a cluttered controller that can't grow. we should have asked the next question: What is Barking? its a sound that dogs can make. can dogs make other sounds? yes.

So what we REALLY need - before Barking - is a simple method in the Controller called makeDogSound or getDogSound etc, which then calls a Model DogSounds.

Then we can easily add more types of dog sounds to the Model - whine, growl, bark, woof - and the Controller is not changed! We can send different types of dog sounds to the view - again the controller is not changed in any way - its retrieving the sound from the model, and sending it to the view.

the controller is like a mailman - he picks up letters and delivers them. he does not look inside the letter!

eventually the DogSounds model could reference other models depending upon the type of dog. this can get very complex - but the structure in the controller - and how it delivers the assets to the view - remains consistent.

| improve this answer | |
  • I get that, but where is the control? Is it a separate class? In that case, would there be a DogModel and DogControl class? – sinθ Mar 21 '13 at 0:25
  • Yes its separate. the Controller is going to have the most general abstract name and methods - because its in the center - and its issuing commands. So the controller is a simple name like Dog, which asks for a dog sound from the Model, and then the Controller sends that sound to the View. the important thing is when you keep them separate, it makes it much easier to build out. – cartalot Mar 21 '13 at 19:15
  • Objects are generalized functions. Why the authors of some books had the glorious idea to pretend that objects model real-world animals or objects and create these terrible examples, I do not know. But it's never helpful for understanding OOP and is the source of a lot of confusion. – yeoman Mar 21 '17 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.