iOS 设计模式的六大设计原则

iOS设计模式的六大设计原则

• 单一职责
  定义：就一个类而言，应该仅有一个引起它变化的原因。
  定义解读
  　　这是六大原则中最简单的一种，通俗点说，就是不存在多个原因使得一个类发生变化，也就是一个类只负责一种职责的工作。
  优点
  类的复杂度降低，一个类只负责一个功能，其逻辑要比负责多项功能简单的多；
  类的可读性增强，阅读起来轻松；
  可维护性强，一个易读、简单的类自然也容易维护；
  变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
  问题提出
  　　假设有一个类C，它负责两个不同的职责：职责P1和P2。当职责P1需求发生改变而需要修改类C时，有可能会导致原本运行正常的职责P2功能发生故障。
  解决方案
  　　遵循单一职责原则。分别建立两个类C1、C2，使C1完成职责P1，C2完成职责P2。这样，当修改类C1时，不会使职责P2发生故障风险；同理，当修改C2时，也不会使职责P1发生故障风险。

• 里氏替换
  定义：里氏替换原则的定义有两种，据说是由麻省理工的一位姓里的女士所提出，因此以其名进行命名。
  定义1：如果对一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1所定义的程序P中在o1全都替换成o2时，程序的行为不发生任何变化，那么T2为T1的子类。
  定义2:所有引用父类的地方都必须能够透明地使用其子类对象。
  定义解读
  其实两个定义所表达的意思都相同，就是在所有父类出现的地方，子类都可以出现，并且将父类对象替换为子类对象的时候，程序不会抛出任何异常或者错误，因此我们需要注意的是，尽量不要重载或者重写父类的方法(抽象方法除外)，因为这样可能会改变父类原有的行为。
  优点
  代码共享，减少创建类的工作量，每个子类都拥有父类的所有属性和方法；
  提高代码的可重用性；
  提高代码的可扩张性；
  提高产品或项目的开放性。
  缺点
  继承是入侵性的，拥有父类的属性和方法；
  降低代码的灵活性，必须拥有父类的属性和方法；
  增强耦合性，父类属性或方法改变，需要考虑子类。
  问题提出
  有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
  解决方案
  当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
  继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。
  继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

• 迪米特法则
  定义：狭义的迪米特法则定义：也叫最少知识原则(LKP，Least Knowledge Principle)。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
  广义的迪米特法则定义：一个模块设计得好坏的一个重要的标志就是该模块在多大的程度上将自己的内部数据与实现有关的细节隐藏起来。信息的隐藏非常重要的原因在于，它可以使各个子系统之间脱耦，从而允许它们独立地被开发、优化、使用阅读以及修改。
  定义解读
  迪米特法则通常被表述为：Only talk to your immediate friends ( 只和离你最近的朋友进行交互)。什么是最近的朋友？我们知道，每个对象都会与其他对象之间有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，如依赖、关联、组合、聚合等。其中，我们称出现在成员变量、方法参数、方法返回值中的类为最近的朋友，而出现在局部变量中的类则不是最近的朋友。迪米特法则是很好的解耦合手段之一。在网上看到的比较形象的说明这个法则的示例：
  如果你想让你的狗狗跑的话，你会对狗狗说还是对四条狗腿说？
  如果你去店里买东西，你会把钱交给店员，还是会把钱包交给店员让他自己拿？
  优点
  迪米特法则使对象之间的耦合降到最小，符合高内聚低耦合的特性，从而使得类具有很好的可读性和可维护性。
  后面介绍的设计模式中，外观模式（Facade）和中介者模式（Mediator），都是迪米特法则应用的例子。
  问题提出
  类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
  解决方案
  使用迪米特法则，降低类与类之间的耦合。

• 依赖倒置
  高层模块不应该依赖底层模块，二者都应该依赖于抽象；抽象不应该依赖细节，细节应该依赖抽象。
  依赖倒置原则在程序编码中经常运用，其核心思想就是面向接口编程，高层模块不应该依赖底层模块（原子操作的模块），两者都应该依赖于抽象。我们平时常说的“针对接口编程”，不要针对实现编程 就是依赖倒转原则的最好体现，接口就是一种抽象，只要不修改接口声明，大家可以放心大胆调用，至于接口的内部实现则无需关心，可以随便重构。这里，接口就是抽象，而接口的实现就是细节。
  如果不管高层模块还是底层模块，他们都依赖于抽象，具体一点就是接口或者抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他收到影响，这就使得无论高层模块还是底层模块都可以很容易地被复用。
  依赖倒转原则其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计。
  优点
  代码结构清晰，维护容易。
  问题提出
  类A直接依赖类B，假如需要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
  解决方案
  将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
  依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在C#/Java中，抽象指的是接口或者抽象类；在Objective-C中，抽象指的是委托，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。

• 接口隔离
  定义：客户端不应该依赖它不需要的接口；
  一个类对另一个类的依赖应该建立在最小的接口上。
  定义包含三层含义
  1.一个类对另一个类的依赖应该建立在最小的接口上
  2.一个接口代表一个角色，不应该将不同的角色都交给一个接口，因为这样可能会形成一个臃肿的大接口
  3.不应该强迫客户依赖他们从来不用的方法

• 开放-关闭原则
  定义:一个软件实体（如类 模块 函数）应当对扩展开放，对修改关闭
  定义解读
  　　在项目开发的时候，都不能指望需求是确定不变化的，大部分情况下，需求是变化的。那么如何应对需求变化的情况？这就是开放-关闭原则要谈的。
  　　开放-封闭原则的思想就是设计的时候，尽量让设计的类做好后就不再修改，如果有新的需求，通过新加类的方式来满足，而不去修改现有的类(代码)。那么在实际的项目开发中，是否能做到绝对的对修改关闭呢？答案一般也是否定的。既然这样，那么就要求我们在开发前，去找出变化点，然后针对变化点构造抽象，隔离出这些变化。由此可见，实现开闭原则关键是抽象。
  优点
  具有灵活性，通过拓展一个功能模块即可实现功能的扩充，不需修改内部代码。
  具有稳定性，表现在基本功能类不允许被修改，使得被破坏的程度大大下降。

总结

对于设计模式的六大设计原则，单一职责原则主要说明类的职责要单一；里氏替换原则强调不要破坏继承体系；依赖倒置原则描述要面向接口编程；接口隔离原则讲解设计接口的时候要精简；迪米特法则告诉我们要降低耦合；开闭原则讲述的是对扩展开放，对修改关闭。

六大设计原则并没有很明显的界限，当我们在遵守某一个设计原则的时候，可能也遵守了其他的设计原则。设计原则是后面要讲述的设计模式的基础，因此在本系列讲述设计模式之前，对设计原则进行了解说