对于设计模式中七大原则的理解
对于设计模式中七大原则的理解
设计模式中分别是创建型，结构型，行为型，总共有23中设计模式。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
使用设计模式能够使我们开发的程序，易维护、可拓展，可复用。但是在23个设计模式的背后，还有7个开发原则去支撑着设计模式，保证23个设计模式能够易维护、可拓展，可复用。所以这篇文章来解开七大设计原则的神秘面纱。
SOLID 是面向对象设计5大重要原则的首字母缩写，当我们设计类和模块时，遵守 SOLID 原则可以让软件更加健壮和稳定。（迪米特与组合/聚合是后加的）
单一职责原则（SRP：Single responsibility principle）
1.设计原则的概念：
就一个类而言，应该仅有一个引起它变化的原因。
符合单一职责原则的类具有高内聚的特性
2.详细解释
每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。耦 合会影响复用性。
如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
所以要遵守单一职责原则，避免将不同职责的功能或接口写到同一个类中，增加了耦合性。
开闭原则（OCP：Open Closed Principle）
1.设计原则的概念：
软件实体（类、模块、函数等）应该可以扩展，但是不可修改。
对扩展是开放的，对于更改是封闭的。
面对新需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码
2.详细解释
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则。
开闭原则是所有原则中最重要的原则，它是所有原则的“老大”，其他原则是服务于开闭原则的。
里氏替换原则（LSP：liskov substitution principle）
1.设计原则的概念：
子类型必须能够替换掉他们的父类型。所有引用父类的地方必须能透明地使用其子类的对象。
只有当子类可以替换掉父类、软件单位的功能不受影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为
正是由于里氏代换原则，才使得开放-封闭成为了可能。
由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以拓展。
2.详细解释
任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类已经实现了的方法。
里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。
接口隔离原则（ISP：Interface Segregation Principle）
1.设计原则的概念：
客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。
2.详细解释
提供尽可能小的单独接口，而不要提供大的总接口。暴露行为让后面的实现类知道的越少越好。
建立单一接口，不要建立庞大的接口，尽量细化接口，接口中的方法尽量少。
接口是设计时对外部设定的约定，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
依赖倒转原则（DIP：Dependence Inversion Principle）
1.设计原则的概念：
A.高层模块不应该依赖底层模块。两个都应该依赖抽象
B.抽象不应该依赖细节。细节应该依赖抽象。
简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
2.详细解释
跟面向对象的多态意思很相像。
核心思想就是面向接口编程，使用抽象的目的是制定规范，不涉及任何具体的操作，把展示细节的任务交给实现去完成。（跟里氏代换、接口隔离，有很大关系，最后都是为了要维持开闭原则）
采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险，提高代码的可读性和可维护性。
组合/聚合复用原则 （CARP：Combination / aggregation Reuse Principle）
1.设计原则的概念：
尽量使用组合、聚合，尽量不要使用类继承
2.详细解释
合成复用原则就是指在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继承。
在面向对象设计中，可以通过两种基本方法在不同的环境中复用已有的设计和实现，即通过组合/聚合关系或通过继承。
组合/聚合复用原则可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
迪米特法则（LOD：Law of Demeter）
1.设计原则的概念：
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
2.详细解释
类与类之间的关系越密切，耦合度也就越来越大，只有尽量降低类与类之间的耦合才符合设计模式；对于被依赖的类来说，无论逻辑多复杂都要尽量封装在类的内部；每个对象都会与其他对象有耦合关系，我们称出现成员变量、方法参数、方法返回值中的类为直接的耦合依赖，而出现在局部变量中的类则不是直接耦合依赖，也就是说，不是直接耦合依赖的类最好不要作为局部变量的形式出现在类的内部。
一个对象对另一个对象知道的越少越好，即一个软件实体应当尽可能少的与其他实体发生相互作用，在一个类里能少用多少其他类就少用多少，尤其是局部变量的依赖类，能省略尽量省略。同时如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一方法的话，可以通过第三者转发这个调用。
如果本篇博客对您有一定的帮助，大家记得留言+点赞+收藏哦。
- 点赞
- 收藏
- 关注作者
评论（0）