独孤九剑--设计模式(iOS创建型篇)

2023-02-27 本文已影响0人 _小沫

独孤九剑--设计模式(iOS结构型篇)
独孤九剑--设计模式(iOS行为型篇)

前言

如果把开发看做是武林世界，底层原理、算法等就是内功心法，那编程语言、设计模式等无疑是外功招式；只专注一门达到精通级别，有人也能独领风骚；内外兼修那才是至尊王者方能称霸武林；

设计模式就是独孤九剑，剑谱由前辈实践总结，一招一式精妙绝伦，照着修炼亦可大有所为；

设计模式

设计模式就是前人经过实践，归纳总结的一套针对特定问题的代码设计解决方案；它就是一套解决特定问题的模板，在遇到类似问题时，可以直接套用对应的模板，高效、高质量的完成开发；

作用

降低开发成本，提高开发效率；
代码实现更优雅、更容易被他人理解；
提高代码复用率、可维护性、可拓展性；

设计原则

设计模式进行设计时需要遵循六大设计原则：

单一职责
类的设计尽量做到只有一个原因引起变化，一个类只专注做一件事
开闭原则
软件实体如类、模块和方法应该对扩展开放，对修改关闭；
功能迭代修改代码时，我们应尽量通过扩展软件实体的行为来实现变化，而不是通过修改内部原有的代码来完成变化；
依赖倒置原则
高层模块不应该依赖低层模块，两者都应该依赖其抽象；
抽象不应该依赖细节；
细节应该依赖抽象；
在iOS中更加精简的定义就是 面向协议编程
接口分离原则
具体类不应该依赖它不需要的接口；
类间的依赖关系应该建立在最小的接口上；
精简的定义就是：接口/协议尽量细分，如UITableViewDelegate/UITableViewDataSource，都是用于tableView的协议，但是系统按照数据源和事件响应细分了2个
里氏替换原则
所有使用基类的地方必须能透明地使用其子类，也即子类能替代基类使用；
如NSArray使用的地方都可以用NSMutableArray替代
迪米特法则
一个对象应该对其他对象有最少的了解；
A耦合了B，A应该只需知道耦合的对应接口，而不需要知道B更多的细节实现；

UML图

学习、使用设计模式需要读懂UML图（侧重类图），有必要的还需要自己能画图；

UML类图学习：
https://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html
UML图制作：
https://github.com/jgraph/drawio-desktop/releases
drawio支持流程图、UML多种图的制作，简单强大易用；
同时也支持在线编制：
https://app.diagrams.net

类型

创建型
原型模式、单例模式、工厂模式、建造者模式；
结构型
适配器模式、代理模式、外观模式、桥接模式、装饰器模式、组合模式、享元模式
行为型
策略模式、观察者模式、模板方法模式、命令模式、备忘录模式、访问者模式、中介者模式、状态模式、责任链模式

主流的设计模式有20多种，下面只介绍下在iOS中可能比较重要的一些设计模式

单例模式 Singleton Pattern

单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。

适用场景

系统只需要一个实例对象，如系统要求提供一个唯一的文件管理对象；或者需要考虑资源消耗太大而只允许创建一个对象。
客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。

单例模式不应滥用，单例模式的对象是唯一的且可以全局使用，涉及到数据更改容易导致数据错乱、线程不安全等问题，将很难维护；另一个问题是单例会隐性地让毫不相关的类产生耦合等问题；

单例模式应该是iOS开发者最熟悉、最常用的一种模式，很容易理解，这里就不多费笔墨；但是对于熟悉的东西往往容易忽略一些细节；

Objective-C单例的简单实现

@implementation CameraManager

+ (CameraManager *)defaultManager {
    static CameraManager *shareInstance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        if (shareInstance == nil) {
            shareInstance = [[CameraManager alloc] init];
        }
    });
    
    return  shareInstance;
}

@end

可能很多小伙伴编码就到此结束，但这里有个潜在的问题；其他语言，如C++，java等，构造方法可以隐藏。OC中的方法，实际上都是公开的，虽然我们提供了一个方便的类方法的访问入口，但是里面的alloc方法依旧是可以调用到的。也就是说依旧可以使用alloc的方式创建对象，每次alloc都是一个新的实例，也就违背单例模式只有一个实例的作用。

Objective-C单例的完善

无论是采用哪种方式创建，保证给出的对象是同一个；
在对象创建的时候，无论是alloc还是new，都会调用到 allocWithZone方法。在通过拷贝创建对象时，都会会调用到copyWithZone或mutableCopyWithZone方法。因此，可以重写这些方法，让创建的对象唯一。

+ (CameraManager *)defaultManager {
....
            shareInstance = [[super allocWithZone:nil] init];
....
    return  shareInstance;
}

+ (instancetype)allocWithZone:(struct _NSZone *)zone {
    return [CameraManager defaultManager];
}

通过其他方式创建对象时，直接抛错禁止创建
可以是编译时抛错，还可以是运行时抛出异常；

编译报错

@interface CameraManager : NSObject
+ (CameraManager *)defaultManager;

+ (instancetype) alloc __attribute__((unavailable("call sharedInstance instead")));
+ (instancetype) new __attribute__((unavailable("call sharedInstance instead")));
- (instancetype) copy __attribute__((unavailable("call sharedInstance instead")));
- (instancetype) mutableCopy __attribute__((unavailable("call sharedInstance instead")));
@end

运行时抛异常

- (instancetype)init {
    NSAssert(NO, @"There can only be one CameraManager instance.");
    // 或者
//    [NSException raise:NSInternalInconsistencyException format:@"There can only be one CameraManager instance."];
    
    return nil;
}

系统库中就有很多单例应用：UIApplication、NSFileManager、NSNotificationCenter 等等...
实测发现NSFileManager、NSNotificationCenter都没有处理其他alloc的情况；UIApplication使用的是运行时抛错的方式禁用其他创建方式；

Swift单例的实现

基于语言特性，Swift实现单例将特别简单、完美

class CameraManager {
    static let defaultManager = CameraManager()
    
    private init() {}
}

工厂模式

工厂模式主要是为创建对象提供过渡接口，将对象的创建具体细节使用工厂类封装屏蔽起来，提高调用的灵活性；另外对象的创建和对象本身业务处理分离，降低了系统的耦合度，使得两者修改起来都相对容易；

工厂模式可以分为三类：简单工厂模式、工厂方法模式、抽象工厂模式

简单工厂模式 Simple Factory Pattern

简单工厂模式专门定义一个工厂类来负责创建其他类的实例，工厂类可以根据参数的不同返回不同类的实例。被创建的实例通常都具有共同的父类（或实现同一个接口/协议）。

UML类图

factory-simple.png

Factory：工厂角色
负责实现创建所有实例的内部逻辑
Product：抽象产品角色
所创建的对象的父类（抽象类、接口、协议）
ConcreteProduct：具体产品角色
所创建的对象具体类的实例。

示例

App需要使用不同的外接相机，根据连接的wifi名区分不同相机并实例化：
Product：相机公有协议：

@protocol CameraProtocol <NSObject>

@optional
- (void)connect;
- (void)take;

@end

ConcreteProduct：各个具体相机对象

@implementation XhwCamera
- (void)connect {
    NSLog(@"xhw connect");
}

- (void)take {
    NSLog(@"xhw take");
}
@end

@implementation AzyCamera
- (void)connect {
    NSLog(@"azy connect");
}

- (void)take {
    NSLog(@"azy take");
}
@end

// 相机工厂类 负责创建不同相机对象 （对应Factory）
@implementation CameraFactory
+ (id<CameraProtocol>)createCameraWifi:(NSString *)wifi {
    if ([wifi isEqualToString:@"xhw"]) {
        return [[XhwCamera alloc] init];
    } else if ([wifi isEqualToString:@"azy"]) {
        return [[AzyCamera alloc] init];
    }
    
    return nil;
}
@end

调用方使用：

id<CameraProtocol> camera = [CameraFactory createCameraWifi:@"xhw"];
[camera connect];
[camera take];

适用场景

优点
1. 工厂类封装了必要的判断逻辑，决定创建哪个类；使用者不必关心具体的创建逻辑，实现了解耦；同时代码也更容易维护
2. 当存在类似功能的不同类时，使用者使用时容易搞混；交由工厂类统一管理，更方便使用者调用；
缺点
1. 工厂类集中了所有产品创建逻辑，一旦不能工作，整个系统将会受到影响
2. 违背“开闭原则”，一旦添加新产品就必须修改工厂类的逻辑；当产品类越来越多，工厂类的逻辑也会更多更乱，不利于系统扩展和维护
3. 简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

基于以上优缺点，简单工厂模式适用场景：

使用方只知道传入工厂类的参数，并不关心创建对象的逻辑时；
工厂类负责创建的产品类比较少时。

工厂方法模式 Factory Method Pattern

工厂方法模式是在简单工厂模式的基础上，进一步抽象化和推广的模式。工厂方法模式里不再只由一个工厂类决定实例化哪些产品类，而是把产品类的创建交给抽象工厂的子类去完成。

简单工厂模式中工厂类做了大量的创建逻辑，一个工厂耦合多个产品类；工厂方法模式抽象了工厂类，具体的工厂类只负责创建一个产品类，避免了简单工厂的一些缺点；

UML类图

factory-method.png

Product：抽象产品角色；ConcreteProduct：具体产品角色
Factory：抽象工厂角色；ConcreteFactory：具体工厂角色

示例

还是简单工厂那个例子，现在将其重构为工厂方法：

抽象工厂：

@protocol CameraFactoryProtocol <NSObject>
// 实例方法、类方法均可以

// 实例方法
//- (id<CameraProtocol>)createCamera;

// 类方法 创建具体的相机（产品）
+ (id<CameraProtocol>)createCamera;

@end

具体的工厂（有多少种产品就多少种工厂）：

@implementation XhwCameraFactory
+ (id<CameraProtocol>)createCamera {
    return [[XhwCamera alloc] init];
}
@end


@implementation AzyCameraFactory
+ (id<CameraProtocol>)createCamera {
    return [[AzyCamera alloc] init];
}
@end

具体产品类不用更改；
调用方使用：

id<CameraProtocol>camera = [XhwCameraFactory createCamera];
[camera connect];
[camera take];

适用场景

优点
1. 包含了简单工厂的优点
2. 符合开闭原则：新增一种产品时，只需要扩展相应的具体产品类和具体的工厂类，无需修改原有工厂类；
3. 符合单一职责原则：每个具体工厂类只负责创建对应的产品
4. 可以使用实例工厂方法，可以形成基于继承的等级结构
缺点
1. 在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销
2. 一个具体工厂只能创建一种具体产品

基于以上优缺点，工厂方法模式适用场景：

基于简单工厂的适用场景；
工厂只会对应一种产品；
后续可能扩展产品

抽象工厂模式 Abstract Factory Pattern

工厂方法模式在一定程度上优化了简单工厂的缺点，但是其一个具体工厂只能创建一种具体产品；抽象工厂模式就是对工厂方法模式的进一步优化；
抽象工厂模式设计了多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。一个抽象工厂类可以派生出多个具体工厂类。每个具体工厂类可以创建多个具体产品的实例；

UML类图

factory-abstrac.png

AbstractFactory：抽象工厂；ConcreteFactory：具体工厂
AbstractProduct：抽象产品；Product：具体产品

示例

基于工厂方法模式的例子，现在增加一个需求：除了连接相机外还需要支持连接不同厂家的音响设备；还是Xhw和Azy两个厂家，按照工厂方法模式的设计，那么就需要新建一套音响抽象工厂类、2个具体的音响工厂类、1个抽象产品类、2个具体产品类；调用方使用时，也同样需要先创建另一个工厂；
其实不管是相机设备，还是音响设备，虽然是不同产品但是都是相同厂家；相机和音响都属于外接设备，完全可以在高一层的抽象出外接设备工厂；这时相当于把相机和音响当做了一个产品族；

实现代码：

抽象工厂（更高抽象）

@protocol PeripheralFactory <NSObject>

// 外接设备目前支持 Camera、Speaker两种产品
- (id<CameraProtocol>)createCamera;
- (id<SpeakerProtocol>)createSpeaker;

@end

新建新增的抽象产品

@protocol SpeakerProtocol <NSObject>

- (void)connect;
- (void)play;

@end

具体工厂 (创建对应的产品)

@implementation XhwFactory
- (nonnull id<CameraProtocol>)createCamera {
    return [[XhwCamera alloc] init];
}

- (nonnull id<SpeakerProtocol>)createSpeaker {
    return [[XhwSpeaker alloc] init];
}
@end


@implementation AzyFactory
- (nonnull id<CameraProtocol>)createCamera {
    return [[AzyCamera alloc] init];
}

- (nonnull id<SpeakerProtocol>)createSpeaker {
    return [[AzySpeaker alloc] init];
}
@end

使用：

AzyFactory *fc = [[AzyFactory alloc] init];
id<CameraProtocol> camera = [fc createCamera];
[camera connect];
id<SpeakerProtocol> speaker = [fc createSpeaker];
[speaker connect];
[speaker play];

适用场景

先引入2个概念：

产品等级结构 ：产品等级结构即产品的继承结构，如一个抽象类是电视机，其子类有海尔电视机、海信电视机、TCL电视机，则抽象电视机与具体品牌的电视机之间构成了一个产品等级结构，抽象电视机是父类，而具体品牌的电视机是其子类。
产品族 ：在抽象工厂模式中，产品族是指由同一个工厂生产的，位于不同产品等级结构中的一组产品，如海尔电器工厂生产的海尔电视机、海尔电冰箱，海尔电视机位于电视机产品等级结构中，海尔电冰箱位于电冰箱产品等级结构中。

优点
1. 包含工厂方法模式的优点
2. 具体工厂可以创建多个产品
3. 当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是一种非常实用的设计模式
4. 符号开闭原则：增加新的具体工厂和产品族很方便，无须修改已有系统。
缺点
1. 开闭原则的倾斜性（增加新的工厂和产品族容易，增加新的产品等级结构麻烦），抽象工厂角色中设计了所有可能被创建的产品集合，要支持新种类的产品就意味着要对该接口进行扩展，而这将涉及到对抽象工厂角色及其所有子类的修改；
2. 产品等级结构、产品族较多时，代码量也成倍增加；

基于以上优缺点，抽象工厂模式适用场景：

基于工厂方法模式的适用场景；
系统有多个系列产品，而系统中只消费其中某一系列产品

iOS系统中的工厂模式

iOS中有类簇的概率，其实它就是使用了工厂模式；
如 NSArray，NSMutableArray；NSNumber等；

    id arrAlloc = [NSArray alloc];
    NSArray *arr = [arrAlloc init];
    id marrAlloc = [NSMutableArray alloc];
    NSMutableArray *marr = [marrAlloc init];
    NSLog(@"%@", NSStringFromClass([arrAlloc class]));
    NSLog(@"%@", NSStringFromClass([arr class]));
    NSLog(@"%@", NSStringFromClass([marrAlloc class]));
    NSLog(@"%@", NSStringFromClass([marr class]));

输出结果：

__NSPlaceholderArray
__NSArray0
__NSPlaceholderArray
__NSArrayM

NSArray真实类型是__NSArray0，NSMutableArray真实类型
__NSArrayM；在alloc分配内存后，创建的是一个中间对象__NSPlaceholderArray，等到init时才会动态决定创建对应的对象；

Apple并没有开源Foundation源码，但是可以通过GNUStep的Foundation代码窥探其实现，可以发现的确是将创建对象的工作转交给了中间对象；

造者模式 Builder Pattern

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节；

UML类图

builder.png

Builder：抽象建造者，ConcreteBuilder：具体建造者
Director：指挥者，Product：产品角色

示例

我们再完善下上面示例的外接相机代码；
外接相机在connect前，需要保证内部模块都初始化完成；相机现在分为3大部分：拍摄模块，wifi模块，存储模块；

@interface XhwCamera : NSObject<CameraProtocol>

// 实际开发中这3部分比较复杂， 现在为了演示简单都使用字符串替代
@property (nonatomic, strong) NSString *shootModule;
@property (nonatomic, strong) NSString *wifiModule;
@property (nonatomic, strong) NSString *storageModule;

// 拍摄配置 如分辨率、帧率等
@property (nonatomic, strong) NSString *shootConfig;

@end

简单做法
在Camera对象init时，将这3部分一起初始化；
但想象下，如果shootModule，wifiModule，storageModule都比较复杂，需要写一大堆配置代码时Camera的init将也会臃肿复杂：

implementation XhwCamera

- (instancetype)init {
    //...
    //...
    _shootModule = ...
    
    //...
    //...
    _wifiModule = ...
}

当shootModule，wifiModule，storageModule需要调整依赖关系或者顺序关系时，还有当这些模块初始化需要由使用者传入参数时，XhwCamera将也很难维护；

使用建造者模式

抽象建造者，声明建造需要的接口

@protocol CameraBuilderProtocol <NSObject>

- (void)buildShootModule;       // 拍摄模块
- (void)buildWifiModule;       // wifi连接模块
- (void)buildStorageModule;   // 存储模块

// 返回构建对象
- (id<CameraProtocol>)build;

@end

具体建造者：xhw相机

@implementation XhwCameraBuilder

- (instancetype)init {
    if (self = [super init]) {
        _camera = [[XhwCamera alloc] init];
    }
    
    return self;
}

- (void)buildShootModule {
    _camera.shootConfig = @"默认配置";
    //.... 复杂过程
    _camera.shootModule = @"拍摄模块初始完成";
}

- (void)buildStorageModule {
    //.... 复杂过程
    _camera.storageModule = @"存储模块初始完成";
}

- (void)buildWifiModule {
    //.... 复杂过程
    _camera.wifiModule = @"wifi模块初始完成";
}

- (nonnull id<CameraProtocol>)build {
    return _camera;
}

@end

构建的Director，控制builder项及顺序、依赖等

@implementation CameraDirector

- (void)constuctBuilder:(id<CameraBuilderProtocol>)builder {
    [builder buildShootModule];
    [builder buildWifiModule];
    [builder buildStorageModule];
}

@end

使用

XhwCameraBuilder *builder = [[XhwCameraBuilder alloc] init];
CameraDirector *director = [[CameraDirector alloc] init];
[director constuctBuilder:builder];
id<CameraProtocol> camera = [builder build];
[camera connect];

完整的建造者模式
如果拍摄的配置需要由客户设置，而不是使用默认的；builder需要支持参数设置；

以拍摄增加分辨率、帧率配置为例，代码重构如下：

builder增加设置的接口

- (void)setShootConfig:(NSString *)config {
    _camera.shootConfig = config;
}

CameraDirector增加传入参数

- (void)constuctBuilder:(id<CameraBuilderProtocol>)builder resolution:(NSString *)resolution frameRate:(NSString *)frameRate {
    NSString *config = [NSString stringWithFormat:@"拍摄配置：分辨率=%@，帧率=%@", resolution, frameRate];
    // buildShootModule初始化需要在shootConfig之后 这个由Director控制了
    [builder setShootConfig:config];
    [builder buildShootModule];
    [builder buildWifiModule];
    [builder buildStorageModule];
}

另一种方式，可以为不同的配置创建不同的具体建造者；
在使用时，只需要更换不同的建造者就可以创建不同配置的产品实例；
比如新建一个高配的相机builder，相机所有配置都是用更高性能的设置，

@implementation XhwCameraHeightBuilder

- (void)buildShootModule {
    _camera.shootConfig = @"拍摄配置：分辨率=1280x720，帧率=30";
    _camera.shootModule = @"拍摄模块初始完成";
}

- (void)buildStorageModule {
    // ...默认高级配置
    _camera.storageModule = @"存储模块初始完成";
}

适用场景

优点
1. 易于解耦
  将产品本身与产品创建过程进行解耦，可以使用相同的创建过程来得到不同的产品；符号依赖倒置原则。
2. 易于精确控制对象的创建
  将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰
3. 易于拓展
  增加新的具体建造者无需修改原有类库的代码，易于拓展，符合开闭原则。
缺点
如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

基于以上优缺点，该模式适用场景：

需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个子模块（或成员属性）。
需要生成的产品对象的属性相互依赖，需要指定其生成顺序。
隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。

完整代码

参考：
https://www.jianshu.com/p/6e5eda3a51af
https://design-patterns.readthedocs.io/zh_CN/latest/index.html

独孤九剑--设计模式(iOS创建型篇)

前言

设计模式

作用

设计原则

UML图

类型

单例模式 Singleton Pattern

适用场景

Objective-C单例的简单实现

Objective-C单例的完善

Swift单例的实现

工厂模式

简单工厂模式 Simple Factory Pattern

UML类图

示例

适用场景

工厂方法模式 Factory Method Pattern

UML类图

示例

适用场景

抽象工厂模式 Abstract Factory Pattern

UML类图

示例

适用场景

iOS系统中的工厂模式

造者模式 Builder Pattern

UML类图

示例

适用场景

猜你喜欢

热点阅读