设计模式之六大设计原则

为什么要学习设计模式？

要知道设计模式就是软件工程的方法经验的总结，也是可以认为是过去一段时间软件工程的一个最佳实践，要理解，不要死记硬背。掌握这些方法后，可以让你的程序获得以下好处：

• 代码重用性（相同功能的代码，不用多次编写）
• 可读性（编程规范性，便于其他程序员的阅读和理解）
• 可扩展性（当需要增加新的功能时，非常的方便，称为可维护）
• 可靠性（当我们增加新的功能后，对原来的功能没有影响）
• 使程序呈现高内聚，低耦合的特性。

当然设计是有限度的，不能无限的考虑未来的变更情况，否则就会陷入设计的泥潭而无法自拔。方法是死的，人是活，用的时候一定灵活运用，才能发挥它的作用。设计模式中六大设计原则，这些原则可以认为是设计模式的灵昏。下面先对六大设计原则简单梳理一下，然后再详细分析每一个设计原则。

设计模式的六大原则

1. 单一职责原则：一个类或一个接口只干一件事，要实现类的职责单一，这也可以延伸到对方法的理解上，主要目的是为了便于理解代码的业务含义，提高代码的可读性；
2. 里氏替换原则：里氏替换原则的本质是描述父类与子类之间的继承规则，子类对象无论何时都能替换父类对象，子类可以扩展父类的功能，但不能改变父类原有的功能，主要目的是为了防止继承泛滥，增强程序的分健壮性；
3. 依赖倒置原则：是指高层不应该依赖低层，要面向接口编程，主要目的是为了方便的对代码结果进行升级扩展；
4. 接口隔离原则：即用多个专门的接口,而不是用单一的总接口,客户端不应该依赖它不需要的接口，主要目的是功能解耦，高聚合、低耦合；
5. 迪米特法则：一个类对自己所依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部，只和朋友交流，不和陌生人说话，减少代码臃肿
6. 开闭原则：对扩展是开放的，对修改是关闭的，主要目的是为了降低维护带来的新风险；

单一职责原则

单一职责：一个类或接口只负责一项职责

好处：

1. 类的复杂性降低，实现什么职责、具备什么功能都有清晰明确的定义；
2. 可读性提高：类之间的复杂性降低，可读性就提高了；
3. 可维护性提高：可读性提高了，也就更便于维护；
4. 变更引起的风险降低：类或接口具有单一的功能职责，变更的范围变小，受影响的范围也小，风险也就变低了；

单一职责是几个设计原则里最简单，最容易理解，也是最不好把握的，因为职责的划分是仁者见仁，智者见智的，如果职责划分的颗粒度较粗，那就不符合单一职责的原则，或者失去了单一职责原则的意义；如果职责划分的颗粒度较细，也不太好，会引起类或接口的剧增，有过度设计的嫌疑，给维护带来一定的麻烦；因此，在单一职责这个原则上，是需要把据一定的灵活性的，毕竟原则是死的，人是活的嘛。

里氏替换原则

里氏替换原则的目的是增加程序的健壮性，核心思想是所有引用基类的地方必须能够透明地使用子类的对象，具体则体现在四个方面：

1. 子类必须完全的实现父类的方法；
2. 子类也可以有自己的个性；
3. 覆盖或实现父类的方法时，输入参数可以被放大；
4. 覆盖或实现父类的方法时，返回值类型可以被缩小；

好处：

1. 加强程序的健壮性
2. 版本升级时可以做到很好的兼容性，增加子类，原有的子类还可以继续运行；

开闭原则

开闭原则：一个类、接口或方法，对扩展是开放的，对修改是关闭的，具体点就是用抽象来构建框架，用实现来扩展细节，即尽量通过扩展实体的行为来实现变化，而不是通过修改现已有代码来实现变化。相信很多同学对这点是深有体会的，就是在维护一段有很多人反复维护修改过的代码的时候，每一个来改的人改之前都要口士芬芳一番，然后无可奈何的接受现状。

我认为开闭原则是仅次于单一职责的最简单、最需要被实践的原则，虽然简单，但是好处可大大的不简单：

1. 提高软件产品的稳定性：开闭原则要求保持原有代码不变，添加新代码来实现软件的变化，这样可以避免改坏线上功能的情况，避免老用户的流失。
2. 不影响原有测试代码的运行：遵守开闭原则，软件的变化，不会影响到原有的测试代码，避免测试出错。
3. 提高代码的可复用性：面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。
4. 提高软件的可维护性：开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。
5. 使代码更具模块化，易于维护：开闭原则可以让代码中的各功能，以及新旧功能独立存在于不同的单元模块中，一旦某个功能出现问题，可以很快地锁定代码位置作出修改，由于模块间代码独立不相互调用，更改一个功能的代码也不会引起其他功能的崩溃。

依赖倒置原则

依赖倒置原则的核心是面向接口接口编程，主要体现在几个方面：

1. 高层模块不应该依赖低层模块，两者都应该依赖抽象；
2. 抽象不应该依赖细节，细节应该依赖抽象；
3. 依赖关系通过抽象类或接口实现，实现类之间不直接发生依赖关系；
4. 接口或抽象类不依赖于实现类，实现类依赖接口或抽象类；

好处：

1. 降低类间的耦合性：依赖倒置原则可以降低类间的耦合性，使得代码更加健壮，更加耐久。
2. 提高系统的稳定性：依赖倒置原则可以提高系统的稳定性，使得代码更加稳定可靠。
3. 减少并行开发引起的风险：依赖倒置原则可以减少并行开发引起的风险，使得并行开发更加高效。
4. 提高代码的可读性和可维护性：依赖倒置原则可以提高代码的可读性和可维护性，使得代码更加易于理解和维护。

接口隔离原则

接口隔离原则是指类或接口间的依赖应该建立在最小接口上，具体就是：

1. 一个类对一个类的依赖应该建立在最小的接口之上；
2. 要建立单一的接口，不要建立庞大臃肿的接口；
3. 接口要尽量细化，接口中的方法要尽量的少，而不要建立一个庞大的接口供很多的依赖类来调用；

这里有的小伙们可能就有疑问了，这好像与单一职责有点类似呀！是的，确实有点类似，但是完全不同，单一职责强调的是类和接口的职责要单一，并没有强调接口的方法也要少，而接口隔离原则强调的是接口方法的松散程度；

1. 降低耦合度：接口隔离原则将接口细化，减少了不相关的方法和依赖关系，降低了模块之间的耦合度。
2. 提高灵活性：通过细粒度的接口定义，系统更容易适应变化，可以灵活地替换实现，而不影响其他部分的代码。
3. 增强可维护性：接口隔离原则使得代码更加清晰、可读性更高，便于理解和维护。
4. 提高代码复用性：通过接口的细化和适配器模式的使用，可以实现接口的复用，减少重复代码的编写。

迪米特原则

迪米特法则又叫 最少知道原则，即一个类对自己所依赖的类知道的越少越好。具体表现：

1. 对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何细节信息。
2. 两个实体间无需直接通信，可以通过第三方进行间接调用。
3. 迪米特法则还有一个更简单的定义：只与直接的朋友通信。那什么是“直接朋友”呢？直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。我们称出现成员变量、方法参数、方法返回值中的类为直接朋友，而出现在局部变量中的类不是直接朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

好处：

1. 降低类之间的耦合度：迪米特原则要求限制对象之间的直接交互，减少对象之间的依赖关系，避免出现复杂的交互关系和耦合度高的代码。
2. 提高模块的相对独立性：通过迪米特原则，我们可以将对象之间的依赖关系转化为通过第三者间接交互，增加了系统的独立性和可维护性。
3. 提高类的可复用率和系统的扩展性：由于迪米特原则降低了类之间的耦合度，使得类更加独立和可复用，同时也使得系统更加易于扩展和维护。

总结

最后，还是要强调一点，设计原则和设计模式绝对不是灵丹妙药，全用上就是好。当然设计原则有人理解是六种，也有理解是七种的。不管理解是几种，设计模式和设计原则属于方法论的内容，是要帮助我们解决具体的业务问题的，当然需要具体问题具体对待。