iOS 中常见的设计模式

iOS中常见的设计模式

1.工厂方法模式(Factory Method)

提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。

+(instancetype)buttonWithType:(UIButtonType)buttonType;
[NSNumber numberWithBool:YES]
[NSNumber numberWithInt:1]

2.享元模式(Flyweight)

运用共享技术有效地支持大量细粒度的对象,减少同一类对象的大量创建,以减少内存占用,提高项目流畅度。

UITableViewCell的复用

参考链接:

https://www.jianshu.com/p/f9c53b9825e4

3.迭代器模式(Iterator)

提供一种方法顺序访问一个聚合对象中各个元素,而又不暴露该对象的内部表示。

iOS的Block迭代、数组迭代都是迭代器模式的典型实现。

下面就是一种系统自带的迭代器模式。

    NSArray *array = @[@1,@2,@3];
    
    NSEnumerator *enumerator = [array objectEnumerator];
    NSNumber *number;
    while (number = [enumerator nextObject]) {
        /**
         *  do something
         */
    }

另外一种


 

    NSArray *array = @[@"123",@"456",@"789"];
    
    [array enumerateObjectsUsingBlock:^(id  _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
        if ([obj localizedCaseInsensitiveCompare:@"789"]) {
            *stop = YES;
        }
    }];

4.单例模式(Singleton)

保证一个类仅有一个实例,并提供一个访问它的全局访问点。

iOS的UIApplicationDelegate就是一个单列模式的实现。

5.观察者模式(Observer)

定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。

iOS中的KVO、NSNotication都是观察者模式。

6.职责链模式(Chain of Responsibility)

使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。

iOS事件的传递和响应就是职责链模式的实现。

7.备忘录模式(Memento)

在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

https://www.jianshu.com/p/bbcbcc7ea749

iOS对对象的归档接档。

8.原型模式(Prototype)

用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。原型模式是非常简单的一种设计模式, 在多数情况下可被理解为一种深复制的行为。在Objective-C中使用原型模式, 首先要遵循NSCopying协议(OC中一些内置类遵循该协议, 例如NSArray, NSMutableArray等)。还有KVO的实现原理也是原型模式。



作者:SoaringHeart
链接:https://www.jianshu.com/p/b7bc8c842cc2
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
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、付费专栏及课程。

余额充值