设计模式相关理论

一、基本概念

1. 软件设计模式的概念

1）软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结

2）它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案

3）也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用

4）其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性

2. 学习设计模式的意义

设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点

1）可以提高程序员的思维能力、编程能力和设计能力

2）使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期

3）使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强

3. 软件设计模式的基本要素

软件设计模式使人们可以更加简单方便地复用成功的设计和体系结构，它通常包含以下几个基本要素：模式名称、别名、动机、问题、解决方案、效果、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式等，其中最关键的元素包括以下 4 个主要部分

1）模式名称	

	每一个模式都有自己的名字，通常用一两个词来描述，可以根据模式的问题、特点、解决方案、功能和效果来命名。模式名称（PatternName）有助于我们理解和记忆该模式，也方便我们来讨论自己的设计

2）问题

	问题（Problem）描述了该模式的应用环境，即何时使用该模式。它解释了设计问题和问题存在的前因后果，以及必须满足的一系列先决条件

3）解决方案

	模式问题的解决方案（Solution）包括设计的组成成分、它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象的 组合）来解决这个问题		

4）效果

	描述了模式的应用效果以及使用该模式应该权衡的问题，即模式的优缺点。主要是对时间和空间的衡量，以及该模式对系统的灵活性、扩充性、可移植性的影响，也考虑其实现问题。显式地列出这些效果（Consequence）对理解和评价这些模式有很大的帮助

---

二、面向对象设计原则

1. 开闭原则

1）概念

	（1）软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义

	（2）开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求

2）作用	

	开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性

	（1）对软件测试的影响

		软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行

	（2）可以提高代码的可复用性	

		粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性

	（3）可以提高软件的可维护性	

		遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护

3）实现方法		

	（1）可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中

	（2）软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了

4）示例

	分析：分析：Windows 的主题是桌面背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的桌面主题，也可以从网上下载新的主题。这些主题有共同的特点，可以为其定义一个抽象类（Abstract Subject），而每个具体的主题（Specific Subject）是其子类。用户窗体可以根据需要选择或者增加新的主题，而不需要修改原代码，所以它是满足开闭原则的

2. 里式替换

1）概念

	（1）里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理

	（2）里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范

	（3）一个软件如果使用的是一个父类的话， 那么一定适用于其子类， 而察觉不出父类对象和子类对象的区别

	（4）继承必须确保超类所拥有的性质在子类中仍然成立。也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系

	（5）只有当子类可以替换掉父类， 软件单位的功能不受到影响时，父类才能真正被复用， 而子类也能够在父类的基础上增加新的行为

	（6）里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法

2）包含的含义

	（1）子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法

	（2）子类中可以增加自己特有的方法

	（3）当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松

	（4）当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格

3. 依赖倒置

1）概念

	（1）依赖倒置原则（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合

	（2）其核心思想是：要面向接口编程，不要面向实现编程

	（3）依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合

	（4）由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类

	（5）使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成

2）作用

	（1）依赖倒置原则可以降低类间的耦合性	

	（2）依赖倒置原则可以提高系统的稳定性

	（3）依赖倒置原则可以减少并行开发引起的风险

	（4）依赖倒置原则可以提高代码的可读性和可维护性

3）实现方法

	（1）每个类尽量提供接口或抽象类，或者两者都具备

	（2）变量的声明类型尽量是接口或者是抽象类

	（3）任何类都不应该从具体类派生

	（4）使用继承时尽量遵循里氏替换原则	

4. 单一职责原则

1）概念

	（1）单一职责原则（SRP：Single responsibility principle）又称单一功能原则。所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。

	（2）该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

		a. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力

		b. 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费	

2）优点

	单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性

	（1）降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多

	（2）提高类的可读性。复杂性降低，自然其可读性会提高	

	（3）提高系统的可维护性。可读性提高，那自然更容易维护了

	（4）变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响

3）实现方法

	（1）单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验	

	（2）单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用

5. 接口隔离原则

1）概念

	（1）接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法	

	（2）要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用

2）与单一职责原则的对比

	（1）单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离

	（2）单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建		

3）优点

	（1）将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性

	（2）接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性

	（3）如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险

	（4）使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义

	（5）能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码

4）实现方法

	（1）接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑

	（2）为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法

	（3）了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑

	（4）提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情

6. 迪米特法则

1）概念

	（1）如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性

	（2）迪米特法则要求限制软件实体之间通信的宽度和深度

2）优点

	（1）降低了类之间的耦合度，提高了模块的相对独立性

	（2）由于亲合度降低，从而提高了类的可复用率和系统的扩展性

	但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰

3）实现方法

	从依赖者的角度来说，只依赖应该依赖的对象。从被依赖者的角度说，只暴露应该暴露的方法

	（1）在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标	

	（2）在类的结构设计上，尽量降低类成员的访问权限

	（3）在类的设计上，优先考虑将一个类设置成不变类

	（4）在对其他类的引用上，将引用其他对象的次数降到最低

	（5）不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）

	（6）谨慎使用序列化（Serializable）功能

7. 合成复用原则

1）概念

	（1）合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现		
	（2）如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范

2）合成复用原则的重要性

	（1）继承复用的缺点	

		a. 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用

		b. 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护

		c. 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化

	（2）组合/聚合复用的优点
	
		a. 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用

		b. 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口

		c. 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象	

3）实现方法

	（1）合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用

总结

这 7 种设计原则是软件设计模式必须尽量遵循的原则，各种原则要求的侧重点不同。

其中，开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；

里氏替换原则告诉我们不要破坏继承体系；

依赖倒置原则告诉我们要面向接口编程；

单一职责原则告诉我们实现类要职责单一；

接口隔离原则告诉我们在设计接口的时候要精简单一；

迪米特法则告诉我们要降低耦合度；

合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用	

---

参考网址

软件设计模式概述

注：文章是经过参考其他的文章然后自己整理出来的，有可能是小部分参考，也有可能是大部分参考，但绝对不是直接转载，觉得侵权了我会删，我只是把这个用于自己的笔记，顺便整理下知识的同时，能帮到一部分人。
ps : 有错误的还望各位大佬指正,小弟不胜感激