3 Replies - 1063 Views - Last Post: 17 April 2014 - 04:41 PM

#1 lamentofking  Icon User is offline

  • D.I.C Head

Reputation: 0
  • View blog
  • Posts: 164
  • Joined: 03-July 13

Determining MVC Pattern Classes

Posted 17 April 2014 - 08:00 AM

Hello,

I was trying to learn about software development and how the MVC (Model-View-Controller) Pattern comes into play on a set of pre-GUI established classes. Choosing the classes to have a view class seems to be straight-forward in the sense that if I think of the domain from the real-world perspective, every class that the user needs to "view" should have a view class. Now Model and Controller are the two parts I'm having trouble figuring out. How would I know which classes in my domain need a model class and which need a controller class?

Is This A Good Question/Topic? 0
  • +

Replies To: Determining MVC Pattern Classes

#2 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 1940
  • View blog
  • Posts: 4,027
  • Joined: 11-December 07

Re: Determining MVC Pattern Classes

Posted 17 April 2014 - 10:34 AM

I tend to think of it bit differently. Model, View and Control are three different parts of a system.

The model represents the state of the thing the program is trying to represent. The classes will basically encapsulate most of the data in the program. That's not to say they are just bags of data. Good model classes will only have a handful of getters and even fewer setters, but plenty of methods that let the control tell them what to do (fish.swim(), radio.tuneToFrequency(), car.shiftGearUp()) or methods that query the state of the world in a way that is not necessarily getters (fish.hasCollided(otherFish) radio.isTunedIn(), car.hasHigherGear())

I think the view is the exciting bit. The way you describe it, you have a Fish from the model and a FishView in the View. Does that also mean you need a FishTankView, a WaterBubbleView, a PlasticPlantView. I hope not! Parallel sets of objects are a sure sign that classes need to be merged. A Sprite class covers all those views and as long as the model objects implement an interface that Sprite knows about it will work very well.

Even there, you are missing most of the fun. What you've described there is some sort of animation view. What about a 3D animation? From a fish-eye-view? Thinking more outside the box, what about a chart view. These could tell you how hungry the fish are or how far they have swum, or something about the social situation in the fish tank, etc... Another option would be a text view. "You awake to find yourself in a fish bowl to the west there are some fish, north is a plastic plant and a strange bubbling noise comes from the south. You are totally immersed and cannot breathe. What next?"

The great thing about all these views is that they work from the same model. You could even write a program that has all of them on the screen at once. Plenty of computer games do this when they have a 3D first person view and an overhead map.

Finally the control... The best way to think about this is what sort of application are you going to make. It could be a fish tank screen saver, a big-fish-eats-the-smaller-fish computer game, a scientific tracking program for real fish, a text based adventure, a fishing simulator. All would use the same model and could use some or all of the views above. The parts that control what methods get called on the model and compose the views is the Control. Mostly it will be the stuff that varies between the different applications but some of the control will probably be used in all.

Your original question was how to divide up an application that doesn't use MVC. Well, MCV is only one pattern. First, make sure it really is appropriate to what you're doing. Then decide if changes you want to make would be easier or harder with MVC. If you don't need to make any changes then no need to refactor, even if MVC makes sense. Then look at your classes. Some will fit into a category neatly. Others will straddle two or maybe three. In those cases, look to see if the classes can be neatly split or if there is some commonality that can be extracted into one class like the Sprite class I described above.
Was This Post Helpful? 0
  • +
  • -

#3 lamentofking  Icon User is offline

  • D.I.C Head

Reputation: 0
  • View blog
  • Posts: 164
  • Joined: 03-July 13

Re: Determining MVC Pattern Classes

Posted 17 April 2014 - 11:12 AM

Alright. And would you say it is better to use the problem description to determine which classes belong in the MVC pattern or should I use CRC cards?
Was This Post Helpful? 0
  • +
  • -

#4 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 1940
  • View blog
  • Posts: 4,027
  • Joined: 11-December 07

Re: Determining MVC Pattern Classes

Posted 17 April 2014 - 04:41 PM

I don't know. I had to google CRC cards.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1