MVC Object Oriented

I am a little confused as to .. well simply put.. how MVC is completely object oriented?

I know from working with a lot of java and c# that OOP that objects have开发者_高级运维 states and behaviors.

I find that I am separating object actions, and placing them all in my controller rather than keeping them in one implementation (along with the View is where I am most tempted, but obviously you cannot do this).

For example, say I have a balloon object.. Its model holds its state such as its color, location, speed that it moves on screen, direction it moves, etc.. However, if I attempt to put any actions like

-(void)moveBalloon:(CGPoint)destination

this is generally unaccepted in the model because the model only holds data about the object, and the view only draws the object and cannot know about its location, etc.

Maybe I'm thinking about this in an odd way.. I generally think of BalloonView as a separate object from BalloonModel, and the controller as its own object.

Is my thinking completely wrong here?

Also.. In terms of reusability, if I wanted to give this object to someone else to use in their app, I would give them the BalloonView and BalloonModel, but they wouldn't have access to any actions that I've already implemented as part of the Balloon object because they're in the controller.

MVC is all about separating your business logic (the model) from your user interface (views and controllers). On its own, MVC has little to do with Object-Oriented (OO) programming. You could easily write software that follows an MVC design strategy without following an OO strategy.

The core of a program is its business logic. In your balloon example, the model should definitely have a moveBalloon: method if moving balloons is something that your program needs to do. To put it another way, Model code should be capable of doing everything that your program needs to do. It should store program state, handle data, and anything else related to the inner workings of the software. Views should be actual UI elements (windows, buttons, text fields, graphics, etc.) They should usually be "dumb" (i.e. with no business logic built into them). Controllers should handle the inner workings of your UI.

If the user is expected to move that balloon around with the mouse, then a Controller and a View would usually handle all of the clicking and dragging and moving around, while the Model would handle only the pure logic portion: the position of the balloon.

You are partially right. By distributing your balloon into MVC parts you cannot easily hand over view and model and controller. Nevertheless, don't worry, you will see, you still can have a reusable balloon even with MVC. But you need a bit to change your view.

You develop your balloon to run in a MVC application the same way you always do. Give it some setters and getters and call it BalloonView. The balloon only hosts the data that is given to it using these setters.

Then you decide what data is necessary to run the balloon. May be the balloon location. Create the BalloonModel and give it the location properties. In your MVC application the data might be stored in the model tier. Another user of your balloon (another application) may store the data right in the main class or even set up static data while setting up the object. It's up to the user how he/she handles the balloon data.

The controller then connects the balloon with the application. There could be a button that triggers the controller. The controller accesses the BalloonModel, updates it with a new location. The BalloonModel change must be then in some way propagated to the BalloonView. There are different techniques how this can be accomplished. The MVC frameworks typically expect the model to dispatch events and a view mediator to connect this event and the particular view. So the view does not necessary need to know its model. But it may do. In our example, the model will dispatch an UPDATE event, a mediatator will receive that event and update the view's location properties. Another user (application) may leave out a controller entirely by connecting a button directly with the balloon positioning:

onclick: balloonView.x += 5;

You see, even if you do not hand over model and controller, your balloonView can still be reusable.

--

MVC makes sense for applications that have a significant size. Simple applications do not need to follow MVC. This would be overkill. Larger applications need some advanced structuring to easily locate responsibilities such as: Where is the data coming from, what actions are allowed and where can I find them.

UI component developer often create a mini MVC architecture only for a particular component. Model, view and controller are then in the same directory and may be compiled into a binary (my_super_list_component.binary) and reused in other projects.

MVC and OOP:

The different parts of the MVC application communicate via events (or signals or messages). An actor (view, model, or controller) may dispatch such an event, and another actor listens to that event. This is not OOP in the sense that one object knows the other and invokes methods via a defined interface, and this is worrying you.

However, using MVC even encourages a better OOP design! Then let's have all your objects host their data and actions on their own. What connections will you need to let them play together. MVC enables you to limit the necessary connections between objects. This is one of the OOP principles. The other feature of MVC is to encapsulate the entire application responsibilities. Not using MVC requires your application logic to be distributed throughout the code which is not what OOP suggests. MVC lets you encapsulate the different parts of the application and is therefore OOP for the macro level of the application. And - we are on the OOP principles - you easily might change controller or model or view and make them reusable and extensible :D