标签：之七大 软件系统 原则 里氏 开闭 修改 模块 设计模式

从今天起，以后每天学一点点设计模式的知识，同时把自己的学习记录在csdn记录下来，亦分享，亦查阅。 

                                                                                                                                                                             ——题记 

---

目录

 1.开-闭原则

2.单一职责原则

3.里氏替换原则

4.依赖倒转原则

5.合成/聚合复用原则

6.迪米特法则

7.接口隔离原则

---

 

面向对象的可复用设计的第一块基石，便是所谓的“开-闭”原则

 1.开-闭原则（Open Closed Principle，OCP）

       “开-闭”原则讲的是：一个软件实体应当对扩展开放，对修改关闭。这个原则说的是，在设计一个模块的时候，应当使这个模块可以再不被修改的前提下被扩展。换言之，应当可以再不必修改源代码的情况下改变这个模块的行为。

   所有的软件系统都有一个共同的性质，即对它们的需求都会随时间的推移而发生变化。在软件系统面临新的需求时，系统的设计必须是文档的。满足“开闭”原则的设计可以给一个软件系统两个无可比拟的优越性：

• 通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。

• 已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。

   具有这两个优点的软件系统是一个在高层次上实现了复用的系统，也是一个易于维护的系统。

怎样做到“开闭”原则

   咋看起来，不能修改而可以扩展似乎是自相矛盾的。怎么可以同时又不修改、而又可以扩展呢？

抽象化是关键

   解决问题的关键在于抽象化。在像C++语言这样的面向对象的编程语言里面，可以给系统定义出一个一劳永逸、不再更改的抽象设计，此设计允许有无穷无尽的行为在实现层被实现。在C++语言里，可以给出一个或多个抽象C++类或C++接口，规定出所有的具体类必须提供的方法的特征作为系统设计的抽象层。这个抽象层预见了所有的可能扩展，因此在任何扩展情况下都不会改变。这就使得系统的抽象层不需修改，从而满足了“开闭”原则的第二条：对修改关闭。

   同时，由于从抽象层导出了一个或多个新的具体类可以改变系统的行为，因此系统的设计对扩展是开放的，这就满足了“开闭”原则的第一条。

与其他设计原则的关系

   做到“开闭”原则不是一件容易的工作，但是也是有很多规律可循的。这些规律也同样以设计原则的身份出现，但是它们都是“开闭”原则的手段和工具，是附属于“开闭”原则的。

 

2.单一职责原则（Single Responsibility Principle, SRP）

 

单一职责原则 ，顾名思义，就是一个类只负责一个职责。它的定义也很简单：这句话很好理解，就是说，不能有多个导致类变更的原因。

那这个原则有什么用呢，它让类的职责更单一。这样的话，每个类只需要负责自己的那部分，类的复杂度就会降低。如果职责划分得很清楚，那么代码维护起来也更加容易。试想如果所有的功能都放在了一个类中，那么这个类就会变得非常臃肿，而且一旦出现bug，要在所有代码中去寻找；更改某一个地方，可能要改变整个代码的结构，想想都非常可怕。当然一般时候，没有人会去这么写的。

 

当然，这个原则不仅仅适用于类，对于接口和方法也适用，即一个接口/方法，只负责一件事，这样的话，接口就会变得简单，方法中的代码也会更少，易读，便于维护。

 

事实上，由于一些其他的因素影响，类的单一职责在项目中是很难保证的。通常，接口和方法的单一职责更容易实现。

 

单一原则的好处：

代码的粒度降低了，类的复杂度降低了。

可读性提高了，每个类的职责都很明确，可读性自然更好。

可维护性提高了，可读性提高了，一旦出现 bug ，自然更容易找到他问题所在。

改动代码所消耗的资源降低了，更改的风险也降低了。

3.里氏替换原则（Liskov Substitution Principle，LSP）

   里氏替换原则中说，任何基类可以出现的地方，子类一定可以出现。

   里氏替换原则是对“开闭”原则的补充。正如前面所提到的，实现“开闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体体现，所以里氏替换原则是对实现抽象化的具体步骤的规范。

   一般而言，违反里氏替换原则的，也违背“开闭”原则，反过来并不一定成立。

4.依赖倒转原则（Dependency Inversion Principle，DIP）

   依赖倒转原则讲的是，要依赖于抽象，不要依赖于实现。

   看上去依赖倒转原则与“开闭”原则有很大的相似之处，实际上，它们之间的关系是目标和手段之间的关系。“开闭”原则是目标，而达到这一目标的手段是依赖倒转原则。

   换言之，要想实现“开闭”原则，就应当坚持依赖倒转原则。违反依赖倒转原则，就不可能达到“开闭”原则的要求。

5.合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）

   要尽量使用合成/聚合，而不是继承关系达到复用的目的。

   显然，合成/聚合复用原则是与里氏替换原则相辅相成的，两者又都是对实现“开闭”原则的具体步骤的规范。前者要求设计师首先考虑合成/聚合关系，后者要求在使用继承关系时，必须确定这个关系时符合一定条件的。

6.迪米特法则（LOW OF DEMETER）

   一个软件实体应当与尽可能少的其他实体发生相互作用。

   当一个系统面临功能扩展的时候，其中会有一些模块，它们需要修改的压力比其他一些模块要打。最后的结果可能是这些模块需要修改或者不需要修改。但是不论是哪一种情况，如果这些模块是相对孤立的，那么它们就不会将修改的压力传递给其他的模块。

   这就是说，一个遵守迪米特法则设计出来的系统在功能需要扩展时，会相对更容易的做到对修改的关闭。也就是说，迪米特法则是一条通向“开闭”原则的道路。

7.接口隔离原则（Interface Segregation Principle，ISP）

   应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。

   显然，接口隔离原则与广义的迪米特法则都是一个软件实体与其他的软件实体的通信的限制。广义的迪米特法则要求尽可能限制通信的宽度和深度。接口隔离原则所限制的是通信的宽度，也就是，通信应当尽可能的窄。

   显然，遵循接口隔离原则与迪米特法则会使一个软件系统在功能扩展的过程当中不会讲修改的压力传递到其他的对象。

 

 

标签：之七大,软件系统,原则,里氏,开闭,修改,模块,设计模式
来源： https://blog.51cto.com/u_2194662/2995847

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。