设计模式基本原则

　　前段时间，聆听一大牛的教诲：“c语言、java语言、C#语言这些都是一些基本的工具，而它们其中的语法、技能都是一些很简单的基础知识，刚接触编码时肯定会有很多的知识、技能你不懂，但你只要碰到并且学习肯定能够熟练使用。所以语言、技能都不重要，重要的是脱离语言工具的思想，编程的思想。设计模式是思想的体现，多多学习肯定没错”。大牛的教诲让小弟收益匪浅，这不开始学习设计模式了。

　　学习设计模式之前，首先明确模式是针对面向对象的，它的三大特性，封装、继承、多态。面向对象设计模式有5大基本原则：单一职责原则、开发封闭原则、依赖倒置原则、接口隔离原则、Liskov替换原则。我们学习的设计模式都是在面向对象的特性以及5大基本原则的基础上衍生而来的具体实现，所以学习之前有必要介绍几大原则的基本概念。

 

单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

单一职责原则可以看做是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这样导致职责依赖，相互之间就会产生原因，大大损伤其内聚性和耦合度。

 

开放封闭原则：对扩展时开放的，对修改是封闭的。

开放封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处：可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样也不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。“需求总是变化”没有不变的软件，所以需要用开放封闭原则来封闭变化满足需求，同时还能保持软件内部的封装体系稳定，不被需求的变化影响。

 

依赖倒置原则：

1 高层模块不应该依赖低层模块。两个都应该依赖抽象。

2 抽象不应该依赖具体（细节）。具体（细节）应该依赖抽象。

依赖倒置其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计了。

 

接口隔离原则：

使用多个专门的接口比使用单一的总接口要好。

一个类对另外一个类的依赖性应当是建立在最小的接口上的。

一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

 

Liskov替换原则：

子类型必须能够替换掉它们的父类型。

任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

 

面向对象最终的设计目标：

• 可扩展性：有了新的需求，新的性能可以容易添加到系统中，不影响现有的性能，也不会带来新的缺陷。
• 灵活性：添加新的功能代码修改平稳地发生，而不会影响到其它部分。
• 可替换性：可以将系统中的某些代码替换为相同接口的其它类，不会影响到系统。

 

基本设计原则介绍完毕，下一篇从简单工厂模式写起。