六大设计原则

六大设计原则

1.单一职责原则

就是一个类只做一件事情。

比如 UIVeiw和 CALayer，UIVeiw只是负责事件传递、事件响应，CALayer负责动画、展示和显示。

2.开闭原则

对修改关闭，对扩展开放。

比如设计一个类，要考虑后续的扩展，对属性和成员变量的定义要谨慎，避免后续的反复去修改。把这个类的数据结构定好了，后续就是提供接口的问题，包括对子类继承，这就是对扩展开放。

3.接口隔离原则

使用对个专门的协议，而不是一个庞大臃肿的协议。

比如系统的 UITableView，有 delegate 和 DataSource两个协议，就是接口隔离的设计原则，delegate负责事件回调，dataSource负责数据源。
协议里面的方法也应该尽量的少。

4.依赖倒置原则

抽象不应该依赖于具体实现，具体实现可以依赖于抽象

所有上层的业务调用，都应该依赖于你所定义的接口，而接口里面的具体实现我不关心，上层业务也感知不到，接口里面的一些东西(属性、变量、参数等)你内部使用就好，也不必要暴露给调用方。

5.里氏替换原则

父类可以被子类无缝替换，且原有功能不受影响

系统的 KVO 就是利用了这个原则，当我们调用 addObserver，系统在运行时动态的创建了一个子类，当我们感觉不到，还以为是使用的原理的类的方法，但实际上系统已经悄无声息的把父类替换成了子类，原有功能不受影响。

6.迪米特法则

一个对象应当对其他对象尽可能少的了解，这样就可以做到高内聚，低耦合。

这样提现出来的编码规范就是：一个对象应该尽量少的知道其他对象的东西，包括成员变量、属性和方法。

责任链模式

一个类 A,其中有一个成员是他自己本身，可以叫 nextResponser

桥接模式

A 类(vc)有三个子类，B 类(列表)有三个子类，把三套数据抽取成一个 B类，都继承于 B

• 使用方
  

适配器模式

如果一个现有类需要适应变化改怎么做？比如一些老的僵尸类，业务比较稳定了，几乎不怎么修改了，如果现在要对其进行一些方法或者成员的修改，风险是很大的。往往原有类不能适应新变化，而又必须使用原有类的方法，那么就可以使用适配器，分为对象适配器、类适配器两种方法。

适配对象的一个成员变量是被适配的对象。比如适配对象的一个 request 方法：

单例模式