1 - 设计模式与设计原则

"每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复的劳动"。 
                                                                                               ---Christopher Alexander

熟悉设计模式，不仅是要理解设计模式的实现代码，
更是要遵循设计原则，针对变化和场景合理使用对应的设计模式。

设计原则构成了设计模式赖以构建的基础。
通过遵循经过验证的设计原则，可以将代码变得更加灵活、更加能够适应变化，而且可维护性更佳。

在现实场景中，通常不会在程序设计之初就硬性套用设计模式， 更实际的做法是
更为实际的做法是，结合身边的代码，使用设计模式来重构代码。

2 - 区分设计模式与设计原则

区分之前，先了解下设计习语、设计模式与架构模式三者的定义：

1. 设计习语（Design Idioms）
   描述与特定编程语言相关的底层模式、技巧、惯用法。
   
2. 设计模式（Design Patterns）
   主要描述的是"类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式等方面"。
   
3. 架构模式（Architectural Patterns）
   描述系统中与基本结构组织关系密切的高层模式，包括子系统划分，职责，以及如何组织它们之间的关系规则。

软件设计模式：
是在软件开发过程中总结得出的一些可重用的解决方案，能针对相应场景解决一些实际的问题。

软件设计原则：
提供行动指南和标准，而不会提供具体解决问题的方法。依照这些准则，能够在程序开发中避免不良的设计。

3 - 区分设计模式的六大原则

原文---设计模式六大原则

单一职责原则（SRP：Single responsibility principle）

不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
一个类只负责一项职责，其逻辑肯定要比负责多项职责简单，提高了类的可读性，也提高系统的可维护性，显著降低变更引起的风险。
在类中新加一个方法的修改方式，虽然违背了单一职责原则，但在方法级别上却是符合单一职责原则的，因为并没有改动原来方法的代码。

里氏替换原则（LSP）

任何父类都应该可以被子类替代，并且保持其行为不变。
通俗来讲，就是子类可以扩展父类的功能，但不能改变父类原有的功能。

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；
• 子类中可以增加自己特有的方法；
  该原则与OCP原则保持一致，确保继承类不会影响父类的行为。

依赖倒置原则（DIP）

将编写的类与具体的实现隔离开来，让这些类依赖于抽象或者接口。
提倡面向接口编程，这确保代码不会与某种实现紧密耦合，从而提高系统的灵活性。

• 高层模块（稳定）不应该依赖低层模块（变化），二者都依赖抽象（稳定）
• 抽象(稳定)不应该依赖于实现细节(变化),实现细节应该依赖于抽象(稳定)

接口分离原则（ISP）

将接口方法按职责划分为若干个组，并且为这些分组指派不同的接口。避免客户端实现一个庞大和一堆用不到的接口。

• 客户端不应该依赖它不需要的接口。
• 接口应该小而完备：一个类对另一个类的依赖应该建立在最小的接口上。

开放封闭原则（OCP）

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
能够在不改变类的内部行为的情况下为类添加新功能，并且避免类被破坏，造成不必要的错误或则bug。
应该避免在原有代码结构上进行更改,而选择去扩展。
因为发生改变的源代码部分需要重新编译、重新测试、重新部署,改变的代价十分高昂。

迪米特法则（最少知道原则）

一个对象应该对其他对象保持最少的了解。
从被依赖者的角度来说：只暴露应该暴露的方法或者属性，即在编写相关的类的时候确定方法/属性的权限。
从依赖者的角度来说，只依赖应该依赖的对象。

4 - 区分单一职责原则和接口隔离原则

• 单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。
• 单一职责原则主要是约束类，其次才是接口和方法，针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。

5 - 参考文章

• 软件开发中的原则
• 设计模式六大原则
• 设计模式原则详解