在开发app的过程中,你将会熟悉以下Cocoa中最常见的设计模式。

           1) 创建类型的:单例模式,抽象工厂模式

           2) 结构化类型的:MVC, Decorator, Adapter, Facade and Composite

           3) 行为类型的:Observer, Memento, Chain of Responsibility andCommand。



(一)MVC

应用场景:最常用设计模式,这种模式是为了代码分离和提高可重用性;视图从Model中分离出来,则同一View可展示不同Model从而实现可重用性;

优势:使系统层次分明,职责分明,易于维护;

原则:对扩展开放-对修改封闭;

Model:数据模型,

View:视图展示,

Controller:控制器,访问模型中的数据,然后用视图进行显示,根据要求监听事件和操作数据,多进行一些逻辑操作;

如果model中数据有任何变化,则通知Controller,Controller更新在View中的数据;View可以通知Controller关于用户的行为,然后Controller要么根据需要或者检索要求的数据去更新Model;

(二)单例模式

应用场景:确保程序运行期某个类,只有一份实例,用于进行资源共享控制。

优势:使用简单,延时求值,易于跨模块。

原则:单一,无论调用多少次有且仅有一个对象,类似全局变量,在整个工程中都可以使用。 (share、default)

实例:[UIApplication sharedApplication]、[NSFileManager defaultManager],都返回一个单例

@interface TestViewManager :  NSObject

// 声明一个类的单例方法
+ (TestViewManager *)defaultTestViewManager;

@end
 
@implementation TestViewManager

+ (TestViewManager *)defaultTestViewManager
{
    static dispatch_once_t onceToken;
    static id testViewManager;
    dispatch_once(&onceToken, ^{
        testViewManager = [self new]; //创建对象
    });
    return testViewManager;
}

@end

(三)代理模式

应用场景:一个对象可以代表或者协助另一个对象的一种机制;

优势:解耦合;

原则:开放-封闭原则;

实例:tableView的数据源delegate,通过protocol的配合,完成委托诉求;

UITableView不知道每个分区里有多少行,计算每个分区的行数的任务交给了UITableView的代理。

(四)观察者模式 KVO

应用场景:一个对象将会通知其他对象的任何状态改变。一般的实现需要一个对象注册成为他感兴趣的状态的观察者,当该状态改变了,所有的观察者对象都会接到通知。

优势:解耦合;

原则:接口隔离原则,开放-封闭原则;

实例:Notification通知中心,注册通知中心,任何位置可以发送消息,注册观察者的对象可以接受;

kvo(Key-Value-Observing ),键值对改变通知的观察者,一个对象可以请求去在一个具体的属性开始变化的时候得到它的一个通知,不论这个属性属于它自己还是另一个对象。

//发出通知
    [[NSNotificationCenter defaultCenter] postNotificationName:@"TestNotification" object:self userInfo:nil];
    
     //注册成为观察者
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(Test:) name:@"TestNotification" object:nil];
    
     //移除所有观察者
    [[NSNotificationCenter defaultCenter] removeObserver:self];

(五)工厂模式

应用场景:工厂方式创建类的实例,多与proxy模式配合,创建可替换代理类。

优势:易于替换,面向抽象编程,application只与抽象工厂和易变类的共性抽象类发生调用关系。

敏捷原则:DIP依赖倒置原则

实例:项目部署环境中依赖多个不同类型的数据库时,需要使用工厂配合proxy完成易用性替换

注意事项:项目初期,软件结构和需求都没有稳定下来时,不建议使用此模式,因为其劣势也很明显,

增 加了代码的复杂度,增加了调用层次,增加了内存负担。所以要注意防止模式的滥用。