设计模式与设计原则简介——及其设计模式学习方法
一、设计模式与设计原则的关系
面向对象的分析设计有很多原则， 这些原则大多从思想层面给我们指出了面向对象分析设计的正确方向， 是我们进行面向对象分析设计时应该尽力遵守的准则。
而设计模式已经是针对某个场景下某些问题的某个解决方案。也就是说这些设计原则是思想上的指导，而设计模式是实现上的手段，因此设计模式也应该遵守这些原则，换句话说，设计模式就是这些设计原则的一些具体体现。
二、为什么不重点讲解设计原则
既然设计模式是设计原则的具体体现， 那么设计模式指导思想就是设计原则了，那为什么不重点讲解设计原则呢？
| 序号 | 不重点讲解设计原则的原因 |
| 1 | 设计原则是思想层面的指导，是高度概括的原则，指明的是设计上的大方向，但是它的具体实现不只是设计模式这一种形式。理论上来说，它可以指导很多不同的实现出来。 |
| 2 | 设计原则只作为一种指导建议，在我们实际的软件开发中，基本上很难做到完全遵守，或多或少的会违反一些设计原则。我们还需要综合业务功能、实现的难度、系统性能、所需的空间与时间等多方面因素考虑。 |
| 3 | 每种设计模式并不是单一的体现某个设计原则；很多设计模式是融合了很多设计原则思想，并不能特别强调设计模式对应某个设计原则；且每个设计模式在应用的时候也有很多考虑因素，不同场景下，突显的设计原则也可能是不一样的。 |
| 4 | 设计模式本身就已经很复杂了，若在深入讲解说明设计原则，会造成没有重点，不能聚焦，不利于学习。 |
三、常见的六种面向对象设计原则
3.1、常见的六种面向对象设计原则
| 序号 | 常见的面向对象设计原则 | 说明 |
| 1 | 单一职责原则【SRP】 (Single Responsibility Principle) | 单一职责原则是指一个类应该仅有一个引起它变化的原因，这个变化原因就是职责。 这个原则看起来是最简单和最好理解的， 但是实际上是很难完全做到的，难点在于如何区分“职责”；这是个没有标准量化的东西，哪些算职责、到底这个职责有多大的粒度、 这个职责如何细化等。；因此，在实际开发中，这个原则也是最容易违反的。 |
| 2 | 开放关闭原则【OCP】 (Open-Closed Principle) | 开放关闭原则是指一个类应该对扩展开放，对修改关闭。一般也被简称为开闭原则，开闭原则是设计中非常核心的一个原则。 这个原则看起来也很简单， 但实际上一个系统中要全部做到遵守开闭原则，几乎是不可能的，也没必要。 适度的抽象可以提高系统的灵活性，使其可扩展、可维护，但是过度地抽象，会极大增加系统的复杂程度。 应该在需要改变的地方应用开闭原则就可以了， 而不用到处使用，从而陷入过度设计。 |
| 3 | 里氏替换原则【LSP】 (Liskov Substitution Principle) | 里氏替换原则是指子类型必须能够替换掉它们的父类型；这很明显是一种多态的使用情况，它可以避免在多态的应用中，出现某些隐蔽的错误。 事实上，当一个类继承了另外一个类， 那么子类就拥有了父类中可以继承下来的属性和操作；理论上来说，此时使用子类型去替换掉父类型，应该不会引起原来使用父类型的程序出现错误；但是，很不幸的是，在某些情况下是会出现问题的（如：若子类型覆盖了父类型的某些方法，或是子类型修改了父类型某些属性的值，那么原来使用父类型的程序就可能会出现错误，因为在运行期间，从表面上看，它调用的是父类型的方法，需要的是父类型方法实现的功能，但是实际运行调用的却是子类型覆盖实现的方法，而该方法和父类型的方法并不一样，于是导致错误的产生。 从另外一个角度来说，里氏替换原则是实现开闭的主要原则之一：开闭原则要求对扩展开放，扩展的一个实现手段就是使用继承；而里氏替换原则是保证子类型能够正确替换父类型，只有能正确替换，才能实现扩展，否则扩展了也会出现错误。 |
| 4 | 依赖倒置原则【DIP】 (Dependence Inversion Principle） | 依赖倒置原则是指要依赖于抽象，不要依赖于具体类；要做到依赖倒置，典型的应该做到： 《1》高层模块不应该依赖于底层模块，二者都应该依赖于抽象。 《2》抽象不应该依赖于具体实现，具体实现应该依赖于抽象。 很多人觉得，层次化调用的时候，应该是高层调用“底层所拥有的接口”，这是一种典型的误解。 事实上，一般高层模块包含对业务功能的处理和业务策略选择，应该被重用，是高层模块去影响底层的具体实现。因此， 这个底层的接口应该是由高层提出的，然后由底层实现的；也就是说底层的接口的所有权在高层模块，因此是一种所有权的倒置。 倒置接口所有权，这就是著名的Hollywood（好莱坞） 原则： 不要找我们，我们会联系你。 |
| 5 | 接口隔离原则【ISP】 (Interface Segregation Principle) | 接口隔离原则是指不应该强迫客户依赖于他们不用的方法。 这个原则用来处理那些比较“庞大”的接口，这种接口通常会有较多的操作声明，涉及到很多的职责。客户在使用这样的接口的时候，通常会有很多他不需要的方法，这些方法对于客户来讲，就是一种接口污染，相当于强迫用户在一大堆“垃圾方法”中去寻找他需要的方法。因此，这样的接口应该被分离，应该按照不同的客户需要来分离成为针对客户的接口。这样的接口中，只包含客户需要的操作声明，这样既方便了客户的使用，也可以避免因误用接口而导致的错误。 分离接口的方式，除了直接进行代码分离之外，还可以使用委托来分离接口，在能够支持多重继承的语言中，还可以采用多重继承的方式进行分离。 |
| 6 | 最少知识原则【LKP】 (Least Knowledge Principle) | 最少知识原则是指只和你的朋友谈话。 这个原则用来指导我们在设计系统的时候，应该尽量减少对象之间的交互，对象只和自己的朋友谈话，也就是只和自己的朋友交互，从而松散类之间的耦合。通过松散类之间的耦合来降低类之间的相互依赖，这样在修改系统的某一个部分的时候，就不会影响其他的部分，从而使得系统具有更好的可维护性。 那么究竟哪些对象才能被当作朋友呢？ 最少知识原则提供了一些指导： 《1》当前对象本身。 《2》通过方法的参数传递进来的对象。 《3》当前对象所创建的对象。 《4》当前对象的实例变量所引用的对象。 《5》方法内所创建或实例化的对象。 总之，最少知识原则要求我们的方法调用必须保持在一定的界限范围之内，尽量减少对象的依赖关系。 |
| 7 | 其他原则 | 除了上面提到的这六个常用原则，还有一些大家都熟知的原则如：
|
3.2、设计模式的学习方法
在实际开发和设计中，要遵循简单设计的原则，不要为了模式而模式，不要过度设计，要在合适的地方应用合适的设计模式来解决问题。初学者尤其要注意， 因为刚学会一个东西， 总是跃跃欲试，急于一显身手，往往容易造成设计模式的误用。
本设计模式专栏，需要反复研读实践。 因此，第一次阅读实践时，若发现有些不理解的内容也不要紧，可以在今后的学习和工作中，反复参阅本专栏，以加深对设计模式的理解，获取设计灵感，并把设计模式切实应用到实际项目中去。
最后就是多结合实际的开发经验来思考，看看如何应用模式来解决实际问题、 如何把模式应用到实际的项目中去，再深入地思考模式的本质和设计思想，掌握模式的精髓，这样才能真正做到在实际开发中自如地应用设计模式。祝大家都学有所成。