设计模式
六大设计原则
-
单一职责
- 一个类只负责一件事情，比如UIView和CALayer的职责分离原理，UIVIew只负责事件传递和事件响应，CALayer负责动画、视图的展示。
-
开闭原则
- 对修改关闭、对扩展开放，在项目当中，
- 对修改关闭定义一个类，往往需要考虑到这个类的扩展性，灵活性。对于一个需求考虑到后期多个版本的迭代，这就要求对类的成员变量定义要非常谨慎，得到一个目的尽量避免后期反复修改这个类，
- 地扩展开放，在这个类定义好以后，往往需要做一些子类继承，或者适配器，这个数据结构不会改变。这就是对扩展开放
-
接口隔离原则
- 使用多个专门的协议，而不是一个庞大臃肿的协议uitableview的两个协议可以去解释它，tableviewdelegate专门去做一些用户交互、回调事件，而uitableviewdatasource专门区搞数据源，
- 协议中的方法尽量少
-
依赖倒置原则
- 抽象不应该依赖于具体实现，具体实现可以依赖抽象
- 在定义一些数据访问，比如说增删改查，依赖于你所定义的一些抽象的接口。而具体接口内部具体实现，用数据库也好还是用文件也好以及用plist、userdefalut，对上层业务来讲，它应该是感知不到的，这就体现出了通过抽象接口来去反转依赖，对于业务来讲它值依赖于我们的接口定义，比如说增删改查，对于内部实现采用哪种增删改查上层是不关注的，没必要将存储方案变量也好参数也好暴漏给使用方，这就体现具体实现可以依赖抽象，而抽象不应该依赖于具体实现。
-
里氏替换原则
- 父类可以被子类无缝替换，且原有功能不受任何影响
- 当调用Addobserver方法时，系统在动态运行时，悄悄的创建了一个子类NSNotifing_person，然后我们虽然感受到的是使用原有的父类，而实际上使用的类已经被系统悄无声息的替换对应的子类，而我们感知的是还是使用原有的类。这就体现了这个设计原则
-
迪米特法则
- 一对对象应当对其他对象有尽可能少的了解
- 高内聚、低耦合
- 每一个对象内部定义的变量、方法，在不影响其他类对象使用的情况下，尽量少的暴漏给外部使用，这就是迪米特法则，比如一些第三方库的编写
责任链
在开发过程中有这么一条任务，
业务A->业务B->业务C 然后产品经理过来 业务C->业务B->业务A
责任链的类构成，一个类对象的成员变量，这个成员变量的类型和缘由的类是一样的，这就构成一个基础的实例。
业务A->业务B->业务C 然后产品经理过来 业务C->业务B->业务A
总结：
在创刊Business对象的时候设置它的nextBusiness对象，这样就能简单的修改业务逻辑的顺序。
BusinessC->BusinessB->BusinessA
桥接
同一套列表，对应的网络数据A，编程网络数据B，又变成了网络数据C，而这几次变化是并存的，通过一些逻辑判断后端来控制应该使用哪套数据，面对这个问题谈谈你的看法？
类构成：
抽象A有一个成员变量抽象B就可以说是构成了桥接模式的关键
抽象A有三个子类，抽象B也有3个子类。
适配器
一个现有类需要适应变化的问题？
在开发过程中，有一个类在很久之前就已经创建，并且运行还是相当的稳定，如果说想要使用新的接口，而新接口之中还需要去使用旧的接口
对象适配器
角色 适配对象 被适配对象
适配对象当中以成员变量形式集成被适配对象到适配对象
- (void)request{
//适配逻辑
[被适配对象 某方法];
//适配逻辑
}
类适配器
单例
注意事项：
1、重写+ (id)allocWithZone:(struct _NSZone *)方法，为了防止外界使用这个方法获取新对象
2、创建单例的时候使用[[super allocWithZone:NULL] init]形式创建，因为在类对象本身已经重写了allocWithZone,[self allocWithZone:NULL]会造成循环调用
3、重写copywithzone方法，为了防止外界通过copy创建新的对象
+ (id)sharedInstance
{
// 静态局部变量
static Mooc *instance = nil;
// 通过dispatch_once方式 确保instance在多线程环境下只被创建一次
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
//规避当在单例初始化单例的时候，重写了allocWithZone方法，那么我们在初始化的时候使用allocWithZone创建会出现循环调用，所以使用super初始化
// 创建实例
//第一点
instance = [[super allocWithZone:NULL] init];
});
return instance;
}
//第二点
// 重写方法【必不可少】
//外界可能通过allocwithZone来创建这个对象，所以我们需要重写这个方法
+ (id)allocWithZone:(struct _NSZone *)zone{
return [self sharedInstance];
}
//第三点
//外界也可能对单例对象进行copy来获取对象，所以我们需要重写这个方法，直接返回self
// 重写方法【必不可少】
- (id)copyWithZone:(nullable NSZone *)zone{
return self;
}
命令
- 行为参数化
- 降低代码重合度
- 可撤销
面试题
请手写单例实现？
你都知道哪些设计原则，请谈谈你的理解
能否用一幅简单的表示桥接模式的主题结构
2种方式：
使用协议抽象，使用base对象抽象
- 抽象角色
- 扩展抽象角色
- 实现抽象角色 多个
- 实现扩展抽象角色 多个
抽象角色持有扩展抽象角色， 在使用的时候我们可以通过服务器的下发、文件读取，或者得到某个条件时候，来给具体抽象角色非配不同的具体扩展抽象角色
UI事件传递机制是怎么样实现的？你对其中运用到的设计模式是怎么理解的？
责任链设计模式：
简单的责任链，和相对复杂的责任链模式
两个特点：
1、使多个对象有机会处理请求。避免了请求者跟接收者之间的耦合
2、 将这些对象连成一条链，并沿着这条链传递请求，直到该请求被处理，或者没有找到该请求
复杂的责任链
角色一： 抽象处理角色 角色二具体处理角色
角色三： 抽象请求角色 角色四 具体请求角色
比如我做过的一个项目，资金报销流程、电脑办公审批流程、假期审批，
抽象处理角色，获取这些权限CEO属于公司执行官最大权限审批金额、CTO技术管理次之权限、审批金额、技术经理次次之权限审批金额、开发者没有权限没有审批金额
具体处理角色就是实现这个抽象类(继承抽象处理角色)， 通过具体处理请求对象进行逻辑业务处理，
报销单有金额权限、电脑办公有行政部门权限、假期审批需要职位权限
需要报销1w块钱买imac，加班报销费，打车报销、假期请多少天假，抽象成请求对象，这就是角色三，根据具体的职位权限去创建相应的
多个处理对象通过NextBusiness对象相连，将具体请求对象发送给处理对象链首位置进行处理。
