常见软件设计原则总结

1 Dont' repeate yourself(DRY)

DRY是一个最简单的法则，也是最容易被理解的，但有可能是最难被应用的（这需要我们在泛型设计上做相当大的努力，这不是一件容易的事）。它意味着，当在两个或者多个地方发现一些相似代码时，我们需要把它们的共性抽象出来形成一个唯一的新方法，并且改变现有地方的代码让它们以合适的参数调用这个新的方法。

2 Keep it simple , stupid (KISS)

KISS 原则在设计上可能最被推崇，在家装设计、界面设计和操作设计上，复杂的东西越来越被众人所鄙视了，而简单的东西越来越被人所认可。宜家简约、高效的家居设计和生产思路；谷歌简约、直接的商业风格，无一例外地遵循了“KISS”原则。而体现在软件设计上：简洁明了的设计框架、直白易懂的代码都是追求的目标。因为，简洁简单意味着犯错概率低，维护成本低。具体体现在：良好的函数名、类名、函数参数列表简短、函数短小精悍、恰当的注释、良好的编程风格等等。

3 Program to an interface, not an implementation

这是设计模式中最基本的原则，注重接口，而不是实现，依赖接口，而不是实现。接口是抽象是稳定的，实现则是多种多样的。该原则的另一种表现形式是面向对象编程中的依赖倒置原则。

4 Law of Demeter，迪米特法则 (Law of Demeter)

又称“最少知识原则”（Principle of Least Knowledge），其来源于 1987 年荷兰大学的一个叫做 Demeter 的项目。克雷格·拉尔曼（Craig Larman）把 Law of Demeter 又称作“不要和陌生人说话”。一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话。一个类里面尽量不要new一些和自己不太有关的对象，而是尽量的通过类本身有联系的对象通过间接联系去和其他的对象产生联系，从而实现低耦合。就好像一个公司的管理模式，部门leader管理该部门手下的员工，部门主管，管理所有部门的leader，如果某部门的员工有什么情况也不会和部门主管进行交流，而是通过他的leader进行相应的沟通

5 面向对象的 S.O.L.I.D 原则

5.1 SRP（Single Responsibility Principle）职责单一原则

关于单一职责原则，其核心的思想是：一个类，只做一件事，并把这件事做好，其只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大地损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为一个模块实现过多的功能点，以保证实体只有一个引起它变化的原因。

5.2 OCP（Open/Closed Principle）- 开闭原则

关于开放封闭原则，其核心的思想是：模块是可扩展的，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。总结就是，如果有新的需求，那么扩展现有的代码，而不是修改现有的代码。这样做的好处是，扩展对legacy的功能没影响，不用做回归测试，影响是收敛的。而修改的话会影响所有legacy的功能，影响是发散的，测试的工作量更多并且bug产生的可能性增加。

5.3 LSP（Liskov substitution principle）- 里氏代换原则

软件工程大师罗伯特·马丁（Robert C. Martin）把里氏代换原则最终简化为一句话：“Subtypes must be substitutable for their base types”。也就是，子类必须能够替换成它们的基类。即子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。另外，不应该在代码中出现 if/else 之类对子类类型进行判断的条件。里氏替换原则 LSP 是使代码符合开闭原则的一个重要保证。正是由于子类型的可替换性才使得父类型的模块在无需修改的情况下就可以扩展。具体可以理解为以下四点：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格

5.4 ISP（Interface Segregation Principle ）- 接口隔离原则

接口隔离原则的意思是把功能实现在接口中，而不是类中，使用多个专门的接口比使用单一的总接口要好。建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。这个链接以C++代码为例，将接口隔离原则讲得比较清楚：

以C/C++语法浅谈六大设计原则（四）——接口隔离原则（Interface Segregation Principle）_南抒一梦的博客-CSDN博客_c++ 接口隔离原则

5.5 DIP（Dependency Inversion Principle）- 依赖倒置原则

高层模块不应该依赖于低层模块的实现，而是依赖于高层抽象。举个例子，墙面的开关不应该依赖于电灯的开关实现，而是应该依赖于一个抽象的开关的标准接口。这样，当我们扩展程序的时候，开关同样可以控制其它不同的灯，甚至不同的电器。也就是说，电灯和其它电器继承并实现我们的标准开关接口，而开关厂商就可以不需要关于其要控制什么样的设备，只需要关心那个标准的开关标准。

6 CCP（Common Closure Principle） - 共同封闭原则

一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包，便影响了包中所有的类。一个更简短的说法是：一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，那么我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。CCP 原则就是把因为某个同样的原因而需要修改的所有类组合进一个包里。如果两个类从物理上或者从概念上联系得非常紧密，它们通常一起发生改变，那么它们应该属于同一个包。CCP 延伸了开闭原则（OCP）的“关闭”概念，当因为某个原因需要修改时，把需要修改的范围限制在一个最小范围内的包里。

7 CRP（Common Reuse Principle）- 共同重用原则

包的所有类被一起重用。如果你重用了其中的一个类，就重用全部。换个说法是，没有被一起重用的类不应该组合在一起。CRP 原则帮助我们决定哪些类应该被放到同一个包里。依赖一个包就是依赖这个包所包含的一切。当一个包发生了改变，并发布新的版本，使用这个包的所有用户都必须在新的包环境下验证他们的工作，即使被他们使用的部分没有发生任何改变。因为如果包中包含未被使用的类，即使用户不关心该类是否改变，但用户还是不得不升级该包并对原来的功能加以重新测试。CCP 则让系统的维护者受益。CCP 让包尽可能大（CCP 原则加入功能相关的类），CRP 则让包尽可能小（CRP 原则剔除不使用的类）。它们的出发点不一样，但不相互冲突。

8 好莱坞原则 - Hollywood Principle

好莱坞原则就是一句话——“don't call us, we'll call you.”。意思是，好莱坞的经纪人不希望你去联系他们，而是他们会在需要的时候来联系你。你call我天经地义，但是请你不要轮询/骚扰我，我通知你。现实生活中乘客(you)打的士到某地，沿途问司机(me)某个景点天经地义；但是不要从上车的第一秒开始，时刻或每隔5秒问司机到了打的的目的地没有，这也太烦人了. 体现在代码中，上层模块（你）call 下层模块（me）天经地义，但是不要轮询（骚扰）下层模块，我通知你（回调）。

9 CoC（Convention over Configuration）- 惯例优于配置原则

简单点说，就是将一些公认的配置方式和信息作为内部缺省的规则来使用。例如，Hibernate 的映射文件，如果约定字段名和类属性一致的话，基本上就可以不要这个配置文件了。你的应用只需要指定不 convention 的信息即可，从而减少了大量 convention 而又不得不花时间和精力啰里啰嗦的东东。配置文件在很多时候相当影响开发效率。Rails 中很少有配置文件（但不是没有，数据库连接就是一个配置文件）。Rails 的 fans 号称其开发效率是 Java 开发的 10 倍，估计就是这个原因。Maven 也使用了 CoC 原则，当你执行 mvn -compile 命令的时候，不需要指定源文件放在什么地方，而编译以后的 class 文件放置在什么地方也没有指定，这就是 CoC 原则。

10 SoC (Separation of Concerns) - 关注点分离

SoC 是计算机科学中最重要的努力目标之一。这个原则，就是在软件开发中，通过各种手段，将问题的各个关注点分开。如果一个问题能分解为独立且较小的问题，就是相对较易解决的。问题太过于复杂，要解决问题需要关注的点太多，而程序员的能力是有限的，不能同时关注于问题的各个方面。正如程序员的记忆力相对于计算机知识来说那么有限一样，程序员解决问题的能力相对于要解决的问题的复杂性也是一样的非常有限。在我们分析问题的时候，如果我们把所有的东西混在一起讨论，那么就只会有一个结果——乱。实现关注点分离的方法主要有两种，一种是标准化，另一种是抽象与包装。标准化就是制定一套标准，让使用者都遵守它，将人们的行为统一起来，这样使用标准的人就不用担心别人会有很多种不同的实现，使自己的程序不能和别人的配合。就像是开发镙丝钉的人只专注于开发镙丝钉就行了，而不用关注镙帽是怎么生产的，反正镙帽和镙丝钉按照标准来就一定能合得上。不断地把程序的某些部分抽象并包装起来，也是实现关注点分离的好方法。一旦一个函数被抽象出来并实现了，那么使用函数的人就不用关心这个函数是如何实现的。同样的，一旦一个类被抽象并实现了，类的使用者也不用再关注于这个类的内部是如何实现的。诸如组件、分层、面向服务等这些概念都是在不同的层次上做抽象和包装，以使得使用者不用关心它的内部实现细节。

11 DbC（Design by Contract）- 契约式设计

DbC 的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。如果在程序设计中一个模块提供了某种功能，那么它要：期望所有调用它的客户模块都保证一定的进入条件：这就是模块的先验条件（客户的义务和供应商的权利，这样它就不用去处理不满足先验条件的情况）。保证退出时给出特定的属性：这就是模块的后验条件（供应商的义务，显然也是客户的权利）。

12 ADP（Acyclic Dependencies Principle）- 无环依赖原则

包（或服务）之间的依赖结构必须是一个直接的无环图形，也就是说，在依赖结构中不允许出现环（循环依赖）。如果包的依赖形成了环状结构，怎么样打破这种循环依赖呢？有两种方法可以打破这种循环依赖关系：第一种方法是创建新的包，如果 A、B、C 形成环路依赖，那么把这些共同类抽出来放在一个新的包 D 里。这样就把 C 依赖 A 变成了 C 依赖 D 以及 A 依赖 D，从而打破了循环依赖关系。第二种方法是使用 DIP（依赖倒置原则）和 ISP（接口分隔原则）设计原则。无环依赖原则（ADP）为我们解决包之间的关系耦合问题。在设计模块时，不能有循环依赖。

13 高内聚，低耦合 & - High Cohesion & Low/Loose coupling

这个原则是 UNIX 操作系统设计的经典原则，把模块间的耦合降到最低，而努力让一个模块做到精益求精。内聚，指一个模块内各个元素彼此结合的紧密程度；耦合指一个软件结构内不同模块之间互连程度的度量。内聚意味着重用和独立，耦合意味着多米诺效应牵一发动全身。