iOS设计模式详解

在软件工程中，(引自维基百科)设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。这个术语是由埃里希·伽玛（Erich Gamma）等人在1990年代从建筑设计领域引入到计算机科学的。设计模式并不直接用来完成代码的编写，而是描述在各种不同情况下，要怎么解决问题的一种方案。面向对象设计模式通常以类别或对象来描述其中的关系和相互作用，但不涉及用来完成应用程序的特定类别或对象。设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象，避免会引起麻烦的紧耦合，以增强软件设计面对并适应变化的能力。

使用设计模式的目的：为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。设计模式使代码编写真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

讲到设计模式，必然要提设计原则，同样为了实现代码复用，要遵循软件设计原则。设计模式就是实现了这些原则，达到了代码的复用、可维护的目的。下面从7种设计原则，23种设计模式，来讲解软件编写过程中用到的这些知识点。

设计原则

编写	全称	中文
S	Single Responsibility Principle	单一职责原则
O	Open Close Principle	开闭原则
L	Liskov Substitution Principle	里氏替换原则
I	Interface Segregation Principle	接口隔离原则
D	Dependence Inversion Principle	依赖倒置原则
L	Law Of Demeter	迪米特法则
C	Composite/Aggregate Reuse Principle CARP	组合/聚合复用原则

前面五种被称为面向对象设计中常用的SOLID原则。

单一职责原则

理解：不同的类具备不同的职责，各司其职。做系统设计是，如果发现有一个类拥有了两种职责，那么就要问一个问题：可以将这个类分成两个类吗果真的有必要，那就分开，千万不要让一个类干的事情太多。

总结：一个类只承担一个职责

例子：我们设计一个订单列表，列表分为待支付、待收货、已收货等列表，那我们是写一个类，使用if判断是哪个类型，然后请求相应的数据，还是写多个类，分别执行各自的功能呢。很多人会觉的写一个类比较省事，但是过多的判断条件，各种职责冗余到一个类中真的好吗，如果待支付列表需要加一些特殊的功能呢，待收货也需要加一些功能呢，那这个类是不是变得条件判断异常的多。所以还是写成多个类，实现各自的逻辑比较好。其实另外我们写列表的Cell，也是一个道理，分成几种类型的Cell去写，而不是一个Cell实现几种类型。

开闭原则

理解：类、模块、函数，可以去扩展，但不要去修改。如果要修改代码，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能保证对整个架构不会产生任何影响，那就没必要搞的那么复杂，直接改这个类吧。

总结：对软件实体的改动，最好用扩展而非修改的方式。

例子：我们设计支付功能的时候，会用到不同的支付方式，我们可以选择在支付的时候使用判断支付条件然后使用不同的支付方式，然而这种设计真的好吗。如果我们添加了一个支付方法或者删除了一个支付方法是不是要改动pay方法的逻辑，那每一次的调整都要改动pay方法的逻辑是不是不合理了，依据开闭原则具体做法应该是设计扩展支付方式来实现不同的支付。

修改之前代码

修改之后

可以看到修改之后的支付，扩展起来是不是很方便，增加支付方式只需要继承PayProcessor就行了，不需要更改pay方法了。

里氏替换原则

理解：一个对象在其出现的任何地方，都可以用子类实例做替换，并且不会导致程序的错误。换句话说，当子类可以在任意地方替换基类且软件功能不受影响时，这种继承关系的建模才是合理的。

总结：子类可以扩展父类的方法，但不应该复写父类的方法。

例子：我们定义汽车的基类，基类里面有行驶的方法，现在我们有个宝马车，宝马车继承汽车基类，也有行驶方法。现在我们想知道宝马车的行驶速度是多少，该怎么设计呢。

修改之前

可以看到我们重写了run方法，增加了汽车行驶速度的逻辑，这样是不满足的里氏替换原则的。因为所有基类Car替换成子类BaoMaCar，run方法的行为跟以前不是一模一样了。

修改之后

接口隔离原则

理解：一个类实现的接口中，包含了它不需要的方法。将接口拆分成更小和更具体的接口，有助于解耦，从而更容易重构、更改。

总结：对象不应被强迫依赖它不使用的方法。

例子：我们定义一个汽车接口，要求实现run等方法。