Once seen what is Cocoa, we know that, for developing applications with Cocoa, it is also necessary to know the concept of MVC (Model View Controller), which is nothing more than a modular design based pattern by which we can made to divide application logic into Model, View and Controller. Thus, the unit code in each design achieves stability and independence from the rest not being affected by changes on the code of other units.
The following are the characteristics of each of the modules of this pattern:
I) Model:
The model portion defines your application's underlying data enguine and is responsible for maintaining the integrity of data. Features:
- It is usually a simple subclass of NSObject, or an instance of NSManagedObject to CoreData.
- Contains a set of instance variables in which stores data.
- Contains methods to access those instance variables.
- Contains methods to generate object instances of other classes.
- Contains a dealloc method (see its useful later).
- It may contain methods for the modification of the internal object models.
- It is reusable.
The view portion defines the user interface for your application and has no explicit knowledge of the origin of the data displayed in that interface. Features:
- Contains a NSView subclass.
- Contains a drawRect method, which will form the basic of all methods of 'drawing'.
- It can be a subclass, but rarely is the case.
- Makes excessive use of Delegates for graphic.
- It is reusable.
III) Controller:
The controller portion acts as a bridge between the model and view and coordinates the passing of data between them. Features:
The controller portion acts as a bridge between the model and view and coordinates the passing of data between them. Features:
- Intermediary between the view and model.
- It is usually a subclass of NSObject.
- Contains outlets and actions for IB.
- Contains instance variables and collections to have and maintain model objects.
- Available methods of handling and composition of model objects.
- Contains the main method of awakeFromNib.*
Also, there is a dessing pattern called delegation, which is a way of modifying complex objects without subclassing them. Instead of subclassing, you use the complex object as is an object, which is referred to as the delegate object. At predefined times, the complex object then calls the methods of the delegate object to give it a chance to run its custom code.
Eveything has been explained in this post is resumed thanks to the following scheme
No comments:
Post a Comment