六大设计原则
单一职责原则、开闭原则、依赖倒置原则、里氏替换原则、接口隔离原则、迪米特法则
单一职责原则
一个类只负责一件事
开闭原则
对修改关闭、对扩展开放
接口隔离原则
使用多个专门的协议、而不是一个庞大臃肿的协议
协议中的方法应当尽量少
依赖倒置原则
抽象不应该依赖于具体实现，具体实现可以依赖于抽象
里氏替换原则
父类可以被子类无缝替换，且原有功能不受任何影响
(KVO使用了此种原则，用runtime生成了一个新的子类NSKVONotifying_类名)
迪米特法则
一个对象对其他对象有尽可能少的了解
高内聚、低耦合
一、责任链模式
使用处理请求的模式，它是让多个处理器都有机会处理该请求，知道其中某个处理成功为止，责任链模式把多个处理器串成链，然后让请求在链传递。如果当前的处理器无法处理则交给下一个处理器处理。
一个关于需求变更的问题？
加入刚开始业务逻辑是 业务A->业务B->业务C
后因为需求变更调用逻辑变为 业务C->业务B->业务A，这里就要用到责任链模式了
责任链模式的类构成
Abstract Class --->成员变量(Abstract Class）
业务类中有一个当前类型的成员变量，而具体的事件处理交由具体的业务对象去处理的。
iOS中责任链的使用
iOS中有许多情况使用到了责任链模式，最典型的就是响应链，一层层的往下传递事件，寻找可以处理事件的对象
下面看下抽象基类的代码实现
BusinessObject.h头文件
#import <Foundation/Foundation.h>
@class BusinessObject;
typedef void(^CompletionBlock)(BOOL handled);
typedef void(^ResultBlock)(BusinessObject *handler, BOOL handled);
@interface BusinessObject : NSObject
// 下一个响应者(响应链构成的关键)
@property (nonatomic, strong) BusinessObject *nextBusiness;
// 响应者的处理方法
- (void)handle:(ResultBlock)result;
// 各个业务在该方法当中做实际业务处理
- (void)handleBusiness:(CompletionBlock)completion;
@end
BusinessObject.m具体实现
@implementation BusinessObject
// 责任链入口方法
- (void)handle:(ResultBlock)result
{
CompletionBlock completion = ^(BOOL handled){
// 当前业务处理掉了，上抛结果
if (handled) {
result(self, handled);
}
else{
// 沿着责任链，指派给下一个业务处理，直到找到可以处理业务的对象为止
if (self.nextBusiness) {
[self.nextBusiness handle:result];
}
else{
// 没有业务处理, 上抛
result(nil, NO);
}
}
};
// 当前业务进行处理
[self handleBusiness:completion];
}
- (void)handleBusiness:(CompletionBlock)completion
{
/*
业务逻辑处理
如网络请求、本地照片查询等
*/
}
@end
然后我们只要将BusinessA，BusinessB，BusinessC都继承自抽象基类创建具体的业务对象，
然后把责任链中nextRespond指向进行更改
BusinessA--->(nextRespond)BusinessB--->(nextRespond)BusinessC改为
BusinessC--->(nextRespond)BusinessB--->(nextRespond)BusinessA即可，跟iOS UI事件响应者链是一样的。
使用场景
有多个对象可以处理同一个请求，动态确定谁可以处理该请求
不明确指定接受者的情况下，给多个对象中的其中一个对象发送请求
动态指定一组对象实现请求
虽然说责任链一般是指当一个对象可以处理时候停止传递，但是在有需求的时候，就算不停止传递也没有关系。
优缺点
优点
责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道是谁处理的，处理者可以不用知道请求的全貌，两者解耦，提高系统的灵活性。缺点
责任链模式有两个非常显著的缺点：一是性能问题，每个请求都是从链头遍历到链尾，特别是在链比较长的时候，性能是一个非常大的问题。二是调试不方便，特别是链条比较长，环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂
二、桥接模式
桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种模式涉及到一个作为桥接的接口，使得抽象层次结构从其实现中分离出来，抽象层定义了供客户端使用的上层的抽象接口，实现层则定义了供抽象层使用的底层接口，实现类的引用被封装与抽象层的实例中时，桥接就形成了。这两种类型的类可被结构化改变而互不影响。
Abstraction是一个抽象基类或者叫控制管理类， 是供开发者直接调用的上层抽象接口的父接口(方法)。它有一个对 Implementor 实例的引用，Implementor 定义了实现类的接口。这个接口不必跟 Abstraction 的接口一致。Implementor 的接口提供基本操作，而 Abstraction 的内部实际操作通过实现类Implementor的调用实现的。当客户端向 Abstraction 的实例发送 operation 消息时，这个方法向 imp 发送 operationImp 消息。实际的 ConcreteImplementator 将作出响应并接收任务
桥接模式的实例应用
比如有一家电视机制造商，他们生产的每台电视机都带有一个遥控器，用户可以用遥控器进行切换频道之类的操作。这里遥控器就是电视机的接口。如果每个电视机型号需要一个专用的遥控器，那么单是遥控器就会导致设计激增。我们可以把遥控器逻辑同实际的电视机型号分离开来，这样电视机型号的改变就不会对遥控器的设计有任何影响。遥控器的同一个设计可以被复用和扩展，而不会影响其他电视机型号。 在面向对象的软件设计中也有类似的情形，从针对不同的实现中，分离出其可被复用的抽象称为桥接模式
实现桥接模式有两种方式比较常见，主要是实现类的具体操作不一样，一种是通过创建实现类的抽象类，然后遵守一个协议，然后通过创建实现类的子类来分别实现不同的业务，另一种就是直接在抽象类中通过方法实现。(其实第一种是把实现的方法列表抽成一个协议的另一种实现方式)
下面两图是对第二种方式的介绍，控制抽象基类A有一个实现抽象基类B，然后分别创建控制类和实现类的子类，来具体实现业务逻辑。
#import <Foundation/Foundation.h>
#import "TVProtocol.h"
NS_ASSUME_NONNULL_BEGIN
/// 遥控器抽象类
@interface AbstractRemoteControl : NSObject
@property (nonatomic, weak) id<TVProtocol> tvProtocol;
- (void)detectTVFunction;
@end
NS_ASSUME_NONNULL_END
#import "AbstractRemoteControl.h"
@implementation AbstractRemoteControl
- (void)detectTVFunction {
NSLog(@"检测电视机具备的功能，由子类来进行实现");
}
@end
要实现的通用功能定义为一个协议列表TVProtocol
#import <Foundation/Foundation.h>
NS_ASSUME_NONNULL_BEGIN
@protocol TVProtocol <NSObject>
@required
// 切换频道
- (void)switchChannel;
// 调节音量
- (void)adjustVolume;
// 电源开关
- (void)powerSwitch;
@end
NS_ASSUME_NONNULL_END
然后再定义一个电视机实现的抽象基类，让其遵守TVProtocol协议
#import <Foundation/Foundation.h>
#import "TVProtocol.h"
NS_ASSUME_NONNULL_BEGIN
/// 电视机抽象类
@interface AbstractTV : NSObject<TVProtocol>
@end
#import "AbstractTV.h"
@implementation AbstractTV
- (void)switchChannel {
NSLog(@"切换频道，由具体的子类来实现");
}
- (void)adjustVolume {
NSLog(@"调节音量，由具体的子类来实现");
}
- (void)powerSwitch {
NSLog(@"电源开关，由具体的子类来实现");
}
然后再创建遥控器抽象类AbstractRemoteControl的子类ConcreteRemoteControl
#import "AbstractRemoteControl.h"
NS_ASSUME_NONNULL_BEGIN
/// 遥控器实例类
@interface ConcreteRemoteControl : AbstractRemoteControl
@end
NS_ASSUME_NONNULL_END
#import "ConcreteRemoteControl.h"
@implementation ConcreteRemoteControl
- (void)detectTVFunction {
[self.tvProtocol switchChannel];
[self.tvProtocol adjustVolume];
[self.tvProtocol powerSwitch];
}
@end
同样的分别创建电视机抽象类AbstractTV的两个子类TVA、TVB（电视型号A和B)
#import "AbstractTV.h"
NS_ASSUME_NONNULL_BEGIN
@interface TVA : AbstractTV
// 重写这三个方法
//- (void)switchChannel;
//- (void)adjustVolume;
//- (void)powerSwitch;
@end
// TVA.m
// DesignPatten
//
// Created by 根哥 on 2023/2/14.
// Copyright © 2023 yangyang. All rights reserved.
//
#import "TVA.h"
@implementation TVA
- (void)switchChannel {
NSLog(@"电视机A 具备了切换频道的功能");
}
- (void)adjustVolume {
NSLog(@"电视机A 具备了调节音量的功能");
}
- (void)powerSwitch {
NSLog(@"电视机A 具备了电源开关的功能");
}
@end
TVB
#import "AbstractTV.h"
NS_ASSUME_NONNULL_BEGIN
@interface TVB : AbstractTV
//// 重写这三个方法
//- (void)switchChannel;
//- (void)adjustVolume;
//- (void)powerSwitch;
@end
#import "TVB.h"
@implementation TVB
- (void)switchChannel {
NSLog(@"电视机B 具备了切换频道的功能");
}
- (void)adjustVolume {
NSLog(@"电视机B 具备了调节音量的功能");
}
- (void)powerSwitch {
NSLog(@"电视机B 具备了电源开关的功能");
}
@end
最后在项目中使用它
- (void)bridgeTVControl{
AbstractRemoteControl *remoteControl = [[ConcreteRemoteControl alloc] init];
AbstractTV *tvProtocol = [[TVA alloc] init];
remoteControl.tvProtocol = tvProtocol;
[remoteControl detectTVFunction];
NSLog(@"///////////////////////////////");
tvProtocol = [[TVB alloc] init];
remoteControl.tvProtocol = tvProtocol;
[remoteControl detectTVFunction];
/**
* 桥接模式：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
* 在本例中，AbstractRemoteControl是抽象部分，TVProtocol是其实现部分。
*/
// Do any additional setup after loading the view, typically from a nib.
}
控制台打印
2023-02-15 11:28:20.714604+0800 DesignPatten[19266:518630] 电视机A 具备了切换频道的功能
2023-02-15 11:28:20.715329+0800 DesignPatten[19266:518630] 电视机A 具备了调节音量的功能
2023-02-15 11:28:20.715958+0800 DesignPatten[19266:518630] 电视机A 具备了电源开关的功能
2023-02-15 11:28:20.716165+0800 DesignPatten[19266:518630] ///////////////////////////////
2023-02-15 11:28:20.716803+0800 DesignPatten[19266:518630] 电视机B 具备了切换频道的功能
2023-02-15 11:28:20.717203+0800 DesignPatten[19266:518630] 电视机B 具备了调节音量的功能
2023-02-15 11:28:20.717706+0800 DesignPatten[19266:518630] 电视机B 具备了电源开关的功能
通过桥接模式的应用，我们可以把抽象部分与实现部分分离，使它们都可以独立的变化。比如在本例中，对AbstractRemoteControl的修改，不会影响到TVProtocol。同样对TVProtocol的修改，也不会影响AbstractRemoteControl。这正是桥接模式带给我们的便利性。
小结
总的来说，桥接模式的本质在于“分离抽象和实现”。也可以对业务进行解耦。
桥接模式的优点：
桥接模式使用聚合关系，解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
提高了系统的可扩展性，可以独立地对抽象部分和实现部分进行扩展。
可减少子类的个数，这个在前面讲电视机示例的时候进行分析了。
桥接模式的缺点：
桥接模式的引入会增加系统的理解与设计难度，由于聚合关系建立在抽象层，要求开发者针对抽象进行设计与编程。
桥接模式要求正确识别出系统中两个独立变化的维度，因此其使用范围具有一定的局限性。
适用场景
通过优缺点的分析，我们可以在如下的情形下使用桥接模式：
不想在抽象与其实现之间形成固定的绑定关系；
抽象及其实现都应可以通过子类化独立进行扩展；
对抽象的实现进行修改不应影响客户端代码；
如果每个实现需要额外的子类以细化抽象，则说明有必要把它们分成两个部分；
想在带有不同抽象接口的多个对象之间共享一个实现。
三、适配器模式
一，适配器的定义
定义: 将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
需求场景: 需要使用以前开发的“一些现存的对象”，但是新环境中要求的接口是这些现存对象所不满足的
四、单例模式
#import "Mooc.h"
@implementation Mooc
+ (id)sharedInstance
{
// 静态局部变量
static Mooc *instance = nil;
// 通过dispatch_once方式 确保instance在多线程环境下只被创建一次
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
// 创建实例
instance = [[super allocWithZone:NULL] init];
// instance = [[Mooc alloc]init];
});
return instance;
}
// 重写方法【必不可少】 ②、防止 [[A alloc] init] 和 new 引起的错误。因为 [[A alloc] init] 和 new 实际是一样的工作原理，都是执行了下面方法
+ (id)allocWithZone:(struct _NSZone *)zone{
return [self sharedInstance];
// return [super allocWithZone:zone];
}
// 重写方法【必不可少】
- (id)copyWithZone:(nullable NSZone *)zone{
return self;
}
@end
