1.12分析和设计
原书再此抨击了市面上许多作者对于OOP设计过于复杂化的论调，因为本质上OOP的诞生就是为了让我们可以更简单的设计出优秀的项目，让我们看看作者的观点，如何利用OOP的特性写出一些“好”的代码吧
1.12.1不要迷失
对于程序编程，我们大多数时期面对的总是比较“常规”的需求，但是如果你在考察某种特殊的方法，而感觉深陷于设计泥潭中不断的“套娃”，时刻记住以下两点：
（1）对象是什么——如何把我着手的项目分割成一系列单独的组件？
（2）他们的接口是什么——我需要把什么消息发给什么对象？
总体来说:
确定项目将会包含哪些对象（比如淘宝包括了购买者、商家、商品、购物车）
确定这些对象有哪些接口（比如购买者会有立即购买、添加购物车）
将是一个项目设计的基石
作者认为整个创建过程应该分为5个阶段：
1.12.2阶段0: 编写一个计划
看起来十分简单，但是实际上入行后的大部分伙伴只把自己定义为所谓的码农，对他们来说会不做任何计划直接开始埋头书写代码
即使你是对整体需求熟悉到在计划上就打算直接开始写代码的人，也应该要从一个计划开始，这将会让你的代码编写过程清晰而又目标，而不是全程只是为了完成工作的那种遥遥无期的感觉
1.12.3阶段1：需求分析、我们要做什么
需求分析的定义是：建立一系列规则，根据他来判断任务什么时候完成，以及客户怎样才满意
说白了，就是一系列的规则，因为它往往是多方参与者一致同意的规则，所以为了节省时间他最好以图表或列表的形式存在（axsure、visio、xmind、powerdesign点了个赞）
这一系列的规则无需注重细枝末节，它应该是一系列：
假如发生了某种情况、系统应该怎么做？
的问答的集合
也就是说，需求分析的核心是 “使用场景” ，在执行需求分析时，我们需要做的是总结出一整套完整的使用场景，一旦完成了这个任务，就可以说抓住了系统需要完成的核心任务
当然，我们并非先知，很有可能出现无法完全总结出系统之后的全部应用场合的情况（比如某购物软件的的需求分析师应该很明显没有考虑到被迫给爸妈点浇水的子女无法叉掉推荐给自己浇水的提示框查看是否浇水成功的情景有多么让人暴躁），只要花费时间，这些问题很自然的就会自己暴露出来。我们不应该苛求“完美”，否则很容易带来焦躁和挫败的情绪
在描述这些系统的需求分析时，我们应该使用最简单的词汇开始描述，再慢慢的围绕他们进行扩充——添加一些简单的名词和动词，自然，名词就是对象，而动词就是对象中整合的方法
在一份完整的需求分析落实后，我们将会能够很简单的进行开发时间的分析及安排——用直觉和经验猜测出一个时间。
1.12.4阶段2：如何构建
在这个阶段，我们所要做的是：构造出一套足够完整的实际方案——解释这其中包含的对象是什么样子的，他们之间是如何沟通的。（说白了，就是一个完整详细的流程图）
在这个阶段，我们往往希望通过图标和所有的参与人员进行沟通，从而确定需要哪些对象、修改哪些对象，我们的最终目标其实是：明确的找出所有的具体对象
1.12.5阶段3：开始构建
让我们的代码做到我们想做的事情，这是我们的终极目标，可以说，变成本质上编程应该以一份艺术性的工作来看待，而不是单纯的所谓“技术活”
在这一阶段，我们应该体验到初期准备的重要性，一份完整的计划将会让代码更易构建和调试，同时，也将使项目更易理解和维护，这将是一套软件能够盈利的必要条件
1.12.6阶段4：校订
可以说，校订的行为是项目开发必须经历的过程，但是对于OOP语言来说，这是一种十分易实现的需求——并且这引出了一种后续会提及的开发模式：递增开发
递增开发的基础思想是：先从系统的核心入手，作为一个框架以实现。
此后，在这个框架的基础上，逐渐的加入“特性”，或者说功能
在此种模式下，后续加入的特性将会作为一个大项目中包含的小项目的形式存在，而不是作为大项目的一部分插入，进一步降低了耦合性与可扩展性，当然，如何设计出一个合适的作为框架的主程序，将会在本书16章进行详细讨论
1.12.7仔细计划带来的利好
其实，究其原因，会有许多同行不乐于书写计划的原因很简单——我们经常会感到，若处处落实的进行计划书写，似乎自己花费在文档的时间远高于编程的时间——但是请记住，不管计划多么的小，有计划都将会远远改进你的项目：没有计划的项目多半都很可能会失败
