设计模式和设计原则
1.1 设计正在“腐烂”的征兆（Symptoms of Rotting Design）
有四个主要的征兆告诉我们该软件设计正在“腐烂”中。它们并不是互相独立的，而是互相关联，它们是过于僵硬、过于脆弱、不可重用性和粘滞性过高。
1. 过于僵硬Rigidity Rigidity 致使软件难以更改，每一个改动都会造成一连串的互相依靠的模块的改动，项目经理不敢改动，因为他永远也不知道一个改动何时才能完成。
2. 过于脆弱Fragility Fragility 致使当软件改动时，系统会在许多地方出错。并且错误经常会发生在概念上与改动的地方没有联系的模块中。这样的软件无法维护，每一次维护都使软件变得更加难以维护。（恶性循环）
3. 不可重用性immobility immobility 致使我们不能重用在其它项目中、或本项目中其它位置中的软件。工程师发现将他想重用的部分分离出来的工作量和风险太大，足以抵消他重用的积极性，因此软件用重写代替了重用。
4. 粘滞性过高viscosity viscosity有两种形式：设计的viscosity和环境的viscosity.当需要进行改动时，工程师通常发现有不止一个方法可以达到目的。但 是这些方法中，一些会保留原有的设计不变，而另外一些则不会（也是说，这些人是hacks）。一个设计如果使工程师作错比作对容易得多，那么这个设计的 viscosity 会很高。
环境的viscosity高是指开发环境速度很慢且效率很低。
2 面向对象的类设计原则
2.1 开放关闭原则The Open Closed Principle （OCP）
A module should be open for extension but closed for modification.一个模块应该只在扩展的时候被打开（暴露模块内部），在修改的时候是关闭的（模块是黑盒子）。
在所有的面向对象设计原则中，这一条重要。该原则是说：我们应该能够不用修改模块的源代码，能更改模块的行为。
2.1.1 动态多态性（Dynamic Polymorphism）
2.1.2 静态多态性（Static Polymorphism）
另外一种使用OCP的技术是使用模板或范型，如Listing 2-3.LogOn函数不用修改代码可以扩展出多种类型的modem. 2.1.3 OCP的体系结构目标（Architectural Goals of the OCP）
通过遵照OCP应用这些技术，我们能创建不用更改内部代码可以被扩展的模块。这是说，在将来我们给模块增添新功能是，只要增加新的代码，而不用更改原 先的代码。 第 3 页，共 17 页使软件完全符合OCP可能是很难的，但即使只是部分符合OCP，整个软件的结构性能也会有很大的提高。我们应该记住，让变化不要波及已经正常工作的代码 总是好的。
2.2 Liskov 替换原则The Liskov Substitution Principle（LSP）
Subclasses should be substitutable for their base classes.子类应该可以替换其基类。
Derived类应该能替换其Base类。也是说，Base基类的一个用户User如果被传递给一个Devrived类而不是Base类作为参数，也能正常的工作。
2.3 依赖性倒置原则The Dependency Inversion Principle （DIP）1
Depend upon Abstractions. Do not depend upon concretions.依赖抽象，不要依赖具体。
如果说OCP声明了OO体系结构的目的，DIP则阐述了其主要机制。依赖性倒置的策略是要依赖接口、或抽象函数、或抽象类，而不是依赖于具体的函数和类。这条原则是支持组件设计、COM、CORBA、EJB等等的背后力量。
2.3.1 依赖抽象Depending upon Abstractions.
实现该原则十分简单。设计中的每一个依赖都应该是接口、抽象类，不要依赖任何一个具体类。
显然这样的限制比较严峻，但是我们应该尽可能的遵守这条原则。原因很简单，具体的模块变化太多，抽象的则变化少得多。而且，抽象是“铰链”点，在这些位置，设计可以弯曲或者扩展，而不用进行更改（OCP）。
2.4 接口隔离原则The Interface Segregation Principle （ISP）
Many client specific interfaces are better than one general purpose interface多个和客户相关的接口要好于一个通用接口。
ISP是另一条在底层支持组件如COM技术的原则。没有它，组件和类的易用性和重用性都会大打折扣。该原则的实质很简单：如果一个类有几个使用者，与其让 这个类载入所有使用者需要使用的所有方法，还不如为每一个使用者创建一个特定的接口，并让该类分别实现这些接口。
3 包体系结构的原则Principles of Package Architecture
类是必不可少的，但对于组织一个设计来说还不够，粒度更大的包有助于此。但是我们应该怎样协调类和包之间的从属关系？下面的三条原则都属于包聚合原则，能对我们有所帮助。
3.1 包聚合原则
3.1.1 发布重用等价原则The Release Reuse Equivalency Principle （REP）1
重用的粒度是发布的粒度。The granule of reuse is the granule of release.一个可重用的元件（组件、一个类、一组类等），只有在它们被某种发布（Release）系统管理以后，才能被重用。用户不愿意使用那些每 次改动以后都要被强迫升级的元件。因此，即使开发者发布了可重用元件的新版本，他也必须支持和维护旧版本，这样才有时间让用户熟悉新版本。
因此，将什么类放在一个包中的判断标准之一是重用，并且因为包是发布的小单元，它们同样也是重用的小单元。体系结构师应该将可重用的类都放在包中。
3.1.2 共同封闭原则The Common Closure Principle （CCP）2
一起变化的类放在一起。Classes that change together， belong together.一个大的开发项目通常分割成很多网状互联的包。管理、测试和发布这些包的工作可不是微不足道的工作。在任何一个发布的版本中，如果改动 的包数量越多，重建、测试和部署也会越多。因此我们应该尽量减少在产品的发布周期中被改动的包的数量，这要求我们将一起变化的类放在一起（同一个 包）。
3.1.3 共同重用原则The Common Reuse Principle （CRP）3
不一起重用的类不应该放在一起。Classes that aren‘t reused together should not be grouped together.对一个包的依赖是对包里面所有东西的依赖。当一个包改变时，这个包的所有使用者都必须验证是否还能正常运行，即使它们所用到的没有任 何改变也不行。
比如我们经常遇到操作系统需要升级。当开发商发布一个新版本以后，我们的升级是迟早的问题，因为开发商将会不支持旧版本，即使我们对新版本没有任何兴趣，我们也得升级。
如果把不一起使用的类放在一起，同样的事情我们也会遇到。一个和我们无关的类的改变也产生包的一个新版本，我们被强迫升级和验证这个包是否影响正常的运行。
3.1.4 包聚合原则之间的张力Tension between the Package Cohesion Principles
这三条原则实际上是互斥的。它们不能被同时满足，因为每一条原则都只针对某一方面，只对某一部分人有好处。REP和CRP都想重用元件的人有好处，CCP 对维护人员有好处。CCP使得包有尽可能大的趋势（毕竟，如果所有的类都属于一个包，那么将只会有一个包变化）；CRP尽量使得包更小。
幸运的是，包并不是一成不变的。实际上，在开发过程中，包的转义和增删都是很正常的。在项目开发的早期，软件建筑师建立包的结构体系，此时CCP占主导地 位，维护只是辅助。在体系结构稳定以后，软件建筑师会对包结构进行重构，此时尽可能的运用REP和CRP，从而大的方便重用元件的人员。
3.2 包耦合原则The Package Coupling Principles.
下面三条原则主要关心包之间的关系。
3.2.1 无依赖回路原则The Acyclic Dependencies Principle （ADP）1
包与包之间的依赖不能形成回路。The dependencies between packages must not form cycles.因为包是发布的粒度。人们倾向于节省人力资源，所以工程师们通常只编写一个包而不是十几个包。这种倾向由于包聚合原则被放大，后来人们将 相关的类组成一组。
因此，工程师发现他们只会改动较少的几个包，一旦这些改动完成，他们可以发布他们改动的包。但是在发布前，他们必须进行测试。为了测试，他们必须编译和连编他们的包所依赖的所有的包。
3.2.2 依赖稳定原则（Stable Dependencies Principle，SDP）
朝稳定的方向依赖Depend in the direction of stability.虽然这条原则看起来很明显，但是关于这方面还是有很多需要说明的地方，稳定性并不一定为大家所了解。
稳定性是什么？站在一个硬币上，这稳定吗？很可能你说不。然而，除非被打扰，硬币将保持那个位置很长时间。硬币没有变化，但是很难认为它是稳定的。稳定性 与需要改动所要做的工作量相关。硬币不稳定是因为只需要很小的工作量能把它翻过来。换个角度，桌子要稳定得多。
对于软件这说明什么？一个软件包很难被改动受很多因素影响：代码大小、复杂度、透明度等等。这些我们先不说，可以肯定的一点是，如果有很多其它的包依赖于 一个软件包，那么该软件包难以改动。一个包如果被许多其它包依赖，那么该包是很稳定的，因为这个包的任何一个改动都可能需要改动很多其它的包。
3.2.3 稳定抽象原则（ Stable Abstractions Principle ，SAP）
稳定的包应该是抽象包。Stable packages should be abstract packages.我们可以想象应用程序的包结构应该是一个互相联系的包的集合，其中不稳定的包在顶端，稳定的包在底部，所有的依赖方向朝下。那些顶端的 包是不稳定而且灵活的，但那些底部的包很难改动。这导致一个两难局面：我们想要将包设计为难以改动的吗？
明显地，难以改动的包越多，我们整个软件设计的灵活性越差。但是好像有一点希望解决这个问题，位于依赖网络底部的高稳定性的包的确难以改动，但是如果遵从OCP，这样的包并不难以扩展。
