共同重用原则（Common Reuse Principle）
一组功能相关的类或一组强耦合的类如果它们具有重用性，则它们应该存在于通一个包中。即一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。换个说法就是，没有被一起重用的类不应该组合在一起。
举个例子：容器类以及与它关联的迭代器类。这些类彼此之间紧密耦合在一起，因此必须共同重用,所以它们应该在同一个包中。
CRP 原则帮助我们决定哪些类应该被放到同一个包里。依赖一个包就是依赖这个包所包含的一切。CRP规定相互之间没有紧密联系的类不应该在同一个包中。
类很少被孤立的重用，一般来说，可重用的类需要与作为该可重用抽象一部分的其它类协作。CRP规定了这些类应该属于同一个包。在这样的一个包中，我们会看到类之间有很多的相互依赖。
当一个包发生了改变，并发布新的版本，使用这个包的所有用户都必须在新的包环境下验证他们的工作，即使被他们使用的部分没有发生任何改变。虽然包中包含未被使用的类，即使用户不关心该类是否改变，但用户还是不得不升级该包并对原来的功能加以重新测试。
共同封闭原则（Common Closure Principle）
一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包，便影响了包中所有的类，而对于其他的包不造成任何影响。一个更简短的说法是：一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，那么我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。
CCP 原则就是把因为某个同样的原因而需要修改的所有类组合进一个包里。如果两个类从物理上或者从概念上联系得非常紧密，它们通常一起发生改变，那么它们应该属于同一个包。这样做会减少软件的发布、重新验证、重新发行的工作量，这增加了可维护性，在大多数的应用程序中，可维护性的重要性是超过可重用性的。
CCP 延伸了开闭原则（OCP）的“关闭”概念，当因为某个原因需要修改时，把需要修改的范围限制在一个最小范围内的包里。
小结
CCP 则让系统的维护者受益，CCP 让包尽可能大（CCP 原则加入功能相关的类）。而CRP 则让包尽可能小（CRP 原则是剔除不使用的类）。它们的出发点不一样，但不相互冲突。
这3个关于包内聚性的原则揭示了在选择要共同组织到包中的类时，必须要考虑可重用性与可开发性之间的相反作用力。在这些作用力和应用的需求之间进行平衡不是一件简单的工作。此外，这个平衡几乎总是动态的。
包的耦合性原则
原则用途：用来指导软件开发者如何处理包之间的相互关系的。
前提条件：我们根据聚合性原则进行了基本的包划分，包的数量和功能基本已经确立，此时我们需要进一步确认这些包之间的相互关系从而验证我们以前规划的包是否合理。
包的划分可能会动态的改变,如当项目的重心从可开发性向可重用性转变时，包的组成很可能会变动并随时间而演化。
无环依赖原则（Acyclic Dependencies Principle）
包（或服务）之间的依赖结构必须是一个直接的无环图形，也就是说，在依赖结构中不允许出现环（循环依赖）。
如果包的依赖形成了环状结构，怎么样打破这种循环依赖呢？
有两种方法可以打破这种循环依赖关系：
- 第一种方法是创建新的包。如果 A、B、C 形成环路依赖，那么把这些共同类抽出来放在一个新的包 D 里。这样就把 C 依赖 A 变成了 C 依赖 D 以及 A 依赖 D，从而打破了循环依赖关系。
- 第二种方法是使用 DIP（依赖倒置原则）和 ISP（接口分隔原则）设计原则。例如：如果A和B是循环依赖，则应该把B中被A依赖的类进行抽象，然后将抽象放入A中，这样A中的类依赖于本包中的抽象而不依赖于B中的实现。
无环依赖原则（ADP）为我们解决包之间的关系耦合问题。在设计模块时，不能有循环依赖。
稳定依赖原则（Stable Dependencies Principle）
包的依赖关系总是朝着稳定的方向进行依赖。 也就是说，要使一个软件包是稳定的或要判别出一个软件包是稳定的，那么肯定可行的方法是让许多其他的软件包依赖于它。
例如：一个软件中的公共函数包一般是稳定的，且业务包、界面包、操作包等都依赖于公共函数包。我们在设计的包的时候通常要实时考虑到这一点，减少互相依赖，尽量让包都依赖于同一个包，从而满足SDP原则。
稳定抽象原则（Stable-Abstractions Principle）
大家都知道抽象和接口一般都是很稳定的，所以包的抽象程度应该和其稳定程度一致。 也就是说：一个相对稳定的包应该是抽象程度很高的包，这样它具有很好的扩展性同时它也是最稳定的。
一个相对不稳定的包应该是具体的，即包中的类都是具体的实现，这样它的具体代码经常需要修改同时它也是最不稳定的。
好莱坞原则（Hollywood Principle）
好莱坞原则就是一句话：“don’t call us, we’ll call you.”。意思是，好莱坞的经纪人不希望你去联系他们，而是他们会在需要的时候来联系你。也就是说，所有的组件都是被动的，所有的组件初始化和调用都由容器负责。
简单来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。
这也就是所谓“控制反转”的概念所在：
- 不创建对象，而是描述创建对象的方式。
- 在代码中，对象与服务没有直接联系，而是容器负责将这些联系在一起。控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。
好莱坞原则就是IoC（Inversion of Control） 或DI（Dependency Injection）]的基础原则。
惯例（约定）优于配置原则（Convention over Configuration）
该原则旨在减少软件开发人员需做决定的数量，获得简单的好处，而又不失灵活性。简单点说，就是将一些公认的配置方式和信息作为内部缺省的规则来使用。
例如，Hibernate 的映射文件，如果约定字段名和类属性一致的话，基本上就可以不要这个配置文件了。你的应用只需要指定不是惯例（convention）的信息即可。
设计不好的框架通常需要多个配置文件，每一个都有许多设置。配置文件在很多时候相当影响开发效率。大量包含太多参数的配置文件通常是过度复杂的应用设计的指标（代码坏味道）。
- Ruby on Rails 中很少有配置文件（但不是没有，数据库连接就是一个配置文件）。Rails 的粉丝号称其开发效率是 Java 开发的 10 倍，估计就是这个原因。
- Maven 也使用了 CoC 原则，当你执行
mvn -compile命令的时候，不需要指定源文件放在什么地方，而编译以后的 class 文件放置在什么地方也没有指定，这就是 CoC 原则。
关注点分离（Separation of Concerns）
SoC 是计算机科学中最重要的努力目标之一。这个原则，就是在软件开发中，通过各种手段，将问题的各个关注点分开。如果一个问题能分解为独立且较小的问题，就是相对较易解决的。问题太过于复杂，要解决问题需要关注的点太多，而程序员的能力是有限的，不能同时关注于问题的各个方面。
正如程序员的记忆力相对于计算机知识来说那么有限一样，程序员解决问题的能力相对于要解决的问题的复杂性也是一样的非常有限。在我们分析问题的时候，如果我们把所有的东西混在一起讨论，那么就只会有一个结果——乱。
实现关注点分离的方法主要有两种：一种是标准化，另一种是抽象与包装。
- 标准化就是制定一套标准，让使用者都遵守它，将人们的行为统一起来，这样使用标准的人就不用担心别人会有很多种不同的实现，使自己的程序不能和别人的配合。就像是开发镙丝钉的人只专注于开发镙丝钉就行了，而不用关注镙帽是怎么生产的，反正镙帽和镙丝钉按照标准来就一定能合得上。
- 不断地把程序的某些部分抽象并包装起来，也是实现关注点分离的好方法。一旦一个函数被抽象出来并实现了，那么使用函数的人就不用关心这个函数是如何实现的。同样的，一旦一个类被抽象并实现了，类的使用者也不用再关注于这个类的内部是如何实现的。诸如组件、分层、面向服务等这些概念都是在不同的层次上做抽象和包装，以使得使用者不用关心它的内部实现细节。
契约式设计（Design by Contract）
所谓契约，也就是合约，规定两个交互物件上的权利和责任。DbC 的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。
如果在程序设计中一个模块提供了某种功能，那么它要：
- 期望所有调用它的客户模块都保证一定的进入条件：这就是模块的先验条件（客户的义务和供应商的权利，这样它就不用去处理不满足先验条件的情况）。
- 保证退出时给出特定的属性：这就是模块的后验条件（供应商的义务，显然也是客户的权利）。
在进入时假定，并在退出时保持一些特定的属性：不变式。
契约就是这些权利和义务的正式形式。我们可以用“三个问题”来总结DbC，并且作为设计者要经常问：
1.它期望的是什么？ 2.它要保证的是什么？ 3.它要保持的是什么？
很多语言都有对这种断言的支持。然而，DbC认为这些契约对于软件的正确性至关重要，它们应当是设计过程的一部分。实际上，DbC提倡首先写断言。
对于一个方法的契约通常包含下面这些信息：
- 可接受和不可接受的值或类型，以及它们的含义
- 返回的值或类型，以及它们的含义
- 可能出现的错误以及异常情况的值和类型，以及它们的含义
- 副作用
- 先验条件
- 后验条件
- 不变式
- (不太常见) 性能上的保证，如所用的时间和空间
总结
本文主要讲解了面向对象设计的5大原则、模块和包的内聚性以及耦合性原则，也讲述了KISS原则（用最简单的解决方案来解决问题）、YAGNI原则（只实现目前需要的功能，避免过度设计）、约定优于配置原则、契约式设计原则等，同时还提到了好莱坞原则，它是IoC（Inversion of Control） 或DI（Dependency Injection）]的基础原则。
