iOS 开发中的几种设计模式

本文介绍了iOS开发中常用的几种设计模式,包括MVC、单例模式、代理模式、观察者模式及工厂模式等。每种模式均阐述了其应用场景、优势、原则及实例,为开发者提供了实用的设计模式指导。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


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

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

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

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


转自: iOS设计模式汇总:http://www.cnblogs.com/pengoeng/p/4759788.html

  iOS开发中的几种设计模式介绍:http://blog.youkuaiyun.com/liwei3gjob/article/details/8926862


(一)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完成易用性替换

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

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


1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义   就一个类而言,应该仅有一个引起它变化的原因。 定义解读   这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出   假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案   遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。   说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值