iOS 几种设计模式

1.代理模式：

其实苹果文档都给出明确的意思：
Delegation is a simple and powerful pattern in which one object in a program acts on behalf of, or in coordination with, another object. The delegating object keeps a reference to the other object—the delegate—and at the appropriate time sends a message to it. The message informs the delegate of an event that the delegating object is about to handle or has just handled. The delegate may respond to the message by updating the appearance or state of itself or other objects in the application, and in some cases it can return a value that affects how an impending event is handled. The main value of delegation is that it allows you to easily customize the behavior of several objects in one central object.
翻译意思是：代理是一个简单而强大的设计模式,代理是程序中的一个对象代表,或配合,另一个对象。委托对象保持对其他对象的引用代理和在适当的时候向其发送消息。消息通知事件的委托,委托对象处理或已经处理。代理可以回复消息通过更新外观或本身或其他对象在应用程序的状态,并在某些情况下,它可以返回一个值,影响如何处理即将发生的事件。代理的主要价值在于,它使您可以轻松地定制一些对象在一个中心对象的行为。

通常格式为@property(nonatomic, assign)id delegate; 即这个代理要遵循某一个协议，也就是说只有遵循了这个协议的类对象才具备代理资格。这同时也要求了代理类必须在头文件中声明遵循这个protocol_name协议并实现其中的@required方法，@optional的方法是可选的。

自定义代理：
在B.h文件中

@optional changeTextDelegate
- (void)changeText：（NSString *）text
@end

@property (nonatomic assign)id<changeTextDelegate>delegate;

在B.m文件中

[self.delegate changeText:text];

在A.m中实现代理方法

- (void)changeText：（NSString *）text
{
    NSString *string = text;
}

总结来说：当一个类的某些功能需要另一个类来完成，但是又不能确定哪个类来实现。
优势：解耦合

2.单例模式

确保某个运行期某个类，只有一个实例，而且自行实例化，并向整个系统提供整个实例，这个实例就是单例。
优势：使用简单，延时求值，易于跨模块
创建单例：
创建一个类 继承nsobject
首先我们需要实现一个静态实例，并初始化，然后置为nil，
static Singleton *singleton = nil

实现一个实例构造方法上声明的静态实例是否为nil，如果是返回一个本来的实例。

+（Singleton *）shareSingleton{
if(singleton == ni){
singleton = [Singleton alloc]init];
}
return singleton;
有单例有2种写法：
第2种：
static dispatch_once_t onceToken ;
    dispatch_once(&onceToken, ^{
        singleton = [[self alloc] init] ;
    }) ;

    return singleton ;
}

3、重写allocWithZone方法，用来保证其他人直接使用alloc和init试图获得一个新实力的时候不产生一个新实例

+ (id) allocWithZone:(NSZone *)zone //第三步：重写allocWithZone方法
{
    @synchronized (self) {
        if (singleton == nil) {
            singleton = [super allocWithZone:zone];
            return singleton;
        }
    }
    return nil;
}

　　4、适当实现allocWitheZone，copyWithZone，release和autorelease。

　　-(id) copyWithZone:(NSZone *)zone
{
    return [Singleton shareSingleton] ;
}

3.MVC模式

模型-视图-控制器（model 、view、controller MVC）

模型对象
模型对象封装了应用程序的数据，并定义操控和处理数据的逻辑和运算，模型模式更改时，它通知控制器对象，控制器对象更新相应的视图。

视图对象
视图对象是应用程序所展现的、可以看见的视图。视图如何将自己绘制出来，并可能对用户的操作做出响应。视图对象的主要目的是显示来自应用程序模型对象的数据，并使对象可编辑。尽管如此，在MVC应用程序中，视图对象通常与模型对象分离。
在iOS应用程序中，所有控件，窗口等都继承与UIView，对应mvc中的v.UIView可以通过委托的方式，交给controller实现。

控制器对象
在应用程序的一个或者多个视图和一个或多个模型对象之间，控制器对象充当媒介。通过它，视图对象了解模型对象的更改。控制器对象还可以为应用程序执行设置和协调任务，来管理其他对象的生命周期。

控制器对象在视图对象中进行用户操作，并将新的或者更改的数据传给模型对象，模型对象更改时，控制器对象会将新的模型对象的数据传给视图对象，视图对象来显示它。

1.model和view永远不能相互通信，只能通过controller来传递
2.controller可以直接与model对话，model可以通过通知（notification）和KVO机制和controller通信。
3.Controller可以直接与View对话，通过outlet,直接操作View,outlet直接对应到View中的控件,View通过action向Controller报告事件的发生(如用户Touch我了)。Controller是View的直接数据源（数据很可能是Controller从Model中取得并经过加工了）。Controller是View的代理（delegate),以同步View与Controller

4.观察者模式

应用场景：一般为model层对controller和view进行通知方式，不关心谁去接受，只负责发送消息。
观察者模式有2中形式
1.kvo
key-value obseving它提供一种机制，当指定的对象的属性被修改后，则对象就会接受到通知。每次指定的被观察的对象的属性被修改后，KVO自动通知相应的观察者。

2.Notification
首先定义回调，即发生通知了我应该做啥事。

• (void)callBack{
  NSLog(@”我收到通知了！”);
  }
  注册通知：

[[NSNotificationCenter defaultCenter] addObserver: self
    selector: @selector(callBack)
    name: @"A类通知"
    object: nil]

;
在程序任何一个地方都可以发送通知

- (void)getNotofocation{
    NSLog(@"get it.");
    //发出通知
    [[NSNotificationCenter defaultCenter] postNotificationName:@"A类通知" object:self];
}

（五）策略模式
应用场景：定义算法族，封装起来，使他们之间可以相互替换。
优势：使算法的变化独立于使用算法的用户
敏捷原则：接口隔离原则；多用组合，少用继承；针对接口编程，而非实现。
实例：排序算法，NSArray的sortedArrayUsingSelector；经典的鸭子会叫，会飞案例。
注意事项：1，剥离类中易于变化的行为，通过组合的方式嵌入抽象基类
2，变化的行为抽象基类为，所有可变变化的父类
3，用户类的最终实例，通过注入行为实例的方式，设定易变行为
防止了继承行为方式，导致无关行为污染子类。完成了策略封装和可替换性。

（六）工厂模式
应用场景：工厂方式创建类的实例，多与proxy模式配合，创建可替换代理类。
优势：易于替换，面向抽象编程，application只与抽象工厂和易变类的共性抽象类发生调用关系。
敏捷原则：DIP依赖倒置原则
实例：项目部署环境中依赖多个不同类型的数据库时，需要使用工厂配合proxy完成易用性替换
注意事项：项目初期，软件结构和需求都没有稳定下来时，不建议使用此模式，因为其劣势也很明显，
增 加了代码的复杂度，增加了调用层次，增加了内存负担。所以要注意防止模式的滥用。

原文：http://blog.csdn.net/liwei3gjob/article/details/8926862