- 软件架构的设计过程，及需要达成的目标和尽量避免的陷阱。
代码复用
无论是开发哪种软件产品，成本和时间都是最重要的。比较少的开发时间意味着可以比竞争对手更早的进入市场，较小的开发成本意味着能够剩下更多的营销资金，获取更多的潜在用户。
代码复用是减少开发成本的方式之一，其目的非常明显，即：与其反复从头开始不如在新的对象中重用已有的代码。
这个想法看起来不错，要想实现已有的代码在全新的代码中工作，需要付出额外的努力，组件间紧密的耦合、对具体类而不是接口的依赖和硬编码的行为都是减低代码灵活性，使得复用这些代码变得更加的困难。
使用设计模式是增加软件组件灵活性并使其易于复用的方法之一，但是这可能会将组件变的更加的复杂。
一般情况下，复用可以分为三个层次，在最底层可以复用类、类库、容器，或是一些类的团体（容器和迭代器）
框架位于最高层，他们能帮助你精简自己的设计，可以明确解决问题所需的抽象概念，然后用类来表示这些概念并定义关系，例如，JUnit是一个小型的框架，也是框架的“hello word”，其中定义了test testcase和testsuite 这及各类及其关系，框架通常比单个类的粒度要大，你可以通过某些构建子类来与框架构建关系，这些子类信奉“别给我们打电话，我们会给你打电话的。”
还有一个中间层次，这是我觉得设计模式所处在的位置，设计模式比框架小更抽象，他们实际上是对一组类的关系及其运动方式的描述，当你从类转向模式，并最终达到框架的过程中，服用程度会不断增加。
中间层次的优点在于模式的服用方式要比框架的风险小，创建框架是一项投入重大且风险很大的工作，模式则能让你独立于具体代码来复用设计思想和理念。
扩展性
需求变化是程序员生命中唯一不变的事情，比如以下场景：
- 你在windows清代发布了一款游戏，现在人们想要Max OS版本。
- 你创建了一个使用方形按钮的GUI框架，但几个月后开始流行原型按钮。
- 你设计了一款优秀的电子上午网站，但仅仅几个月，客户就要增加电话订单功能。
每款软件都要经历着不断的变化，除非它死掉了。
首先，在完成了第一版的程序后，我们就应该做好了从头开始优化重写代码的准备，因为现在你已经能在很多方面更好的理解问题了，同时在专业水平上有很大的提高，所以之前的开发现在看上去可能会显得很糟糕。
其次可能是在你掌控之外的一些事情发生了，导致团队转变最初的思维，比如flash不在被浏览器支持。
最后，就是需求的变更，因为没有任何事物能满足所有人的需求，一些小的改动总是要有的，当然如果有人不断地对你的软件不断的提出问题 ,不断地修复，证明你的软件有人关心这是好事情，在设计架构时，有经验的开发者都会尽量选择支持未来任何可能变更的方式。
