前言
读《大象》的这一章节感觉很有指导意义，虽然工程中不能全部实践，但作为心法来驱动设计是绰绰有余了。
特质
一切都是对象
在面向对象者的眼里，一切有名字的东西都是对象，都应该使用对象的观点来看待它、分析他。哪怕这个东西的名字叫某某业务流程，它仍然应该看作是一个对象，而不是一个过程。这意味着，无论什么时候都应当采用接下来讲述的一些观点和方法来看待和分析事物。
对象都是独立的
独立性是面向对象的一大特点，承认对象的同时就接纳了这一观点。对象与对象之间是天然独立的，知识在某个特定的场景下，他们的某一个特定的实例才相互的联系在一起。
我们获取和分析对象的手段经常是通过分析某个场景，但是需要知道，对象是离散的，他不是因为该场景而存在的。场景中的对象知识对象『映射』到该场景中的一个侧面，我们称之为对象实例。换言之，通过一个场景，我们仅能得到对象的一个侧面的信息。
如果以每一个场景为坐标（维度），那么对象实例就是对象在该坐标上的投影
每个维度就是更高层的抽象。
用例：苹果（假设一筐中有许多苹果，差异很大）
苹果颜色，大小，口感是三个维度，那么简单的，红色，中等大小，脆脆的就是框中苹果们的一个实例。（假设可以根据这三个属性(方面)来确定是一个苹果）
要深入了解对象，我们经常需要分析很多歌该对象的实例所参与的场景，以获得对象的多个侧面，再通过归纳整理这些对象的多个实例抽象出对象的一般特性。这就是对象的分析方法，同时也是使用UML来为对象建模时所采用的方法。从图2.4中，我们看到对象的产生、抽象并不是拍脑袋得来的。对象来源于场景分析，场景分析越多，我们对对象的了解越多，越精确。有过项目经验的读者应该有深刻体会，在做过多个项目以后，会发现在许多项目当中相似的对象或者函数，会产生强烈的想把他们公共化得想法，这就是对象抽象的源动力。
从每个场景看到的仅是对象映射到该场景的一个方面，或者说是一个实例，他仅仅是对象分析的开始。
对象的独立性带来的正是对象的可抽象能力和可扩展能力。
请记住，当采用面向对象的方法时，在需求、分析、设计过程中，你所得到的任何一个有名字的东西，不论是用例、类、包、组件等都是独立于那个场景的，不要将对象局限在那个场景中。
对象都具有原子性
无论在什么时候，在同一抽象层次上，在分析过程中都应当将对象视为一个不可分割的原子，哪怕这个对象的规模很大。例如在分析一个商业过程的时候，对象的规模（粒度）大到如银行、工厂、商场的程度，不论它有多么巨大，只要我们认为它是对象，它与其他对象交互时就是一个整体，不能分割。原子性是抽象层次有意义的重要保证，一旦破坏了原子性，则表示在同一抽象层次上的对象不具备同样的粒度，这使得分析工作陷入混乱。
在分析过程中，对象总有一个边界，永远也不应该打破边界去窥探对象的内部。
形象一些说，对象看上去就像是一个个的鸡蛋，蛋壳就是对象的边界。在分析对象的过程中，我们对它的所有理解都是来自蛋壳。如果因为我们好奇心太重试图了解壳以内的世界，冲动的打破了边界，嗯，的确看到了，好奇心得到了满足，不过很快就后悔了。因为鸡蛋被破坏了，一滩黏黏糊糊的蛋清弄脏了手，很难收拾：P 糟糕的设计就像一堆破了壳的鸡蛋，一片混乱。
我们应当将分析过程中得到的所有对于对象的认识附加在对象边界上，在实现这个对象之前不理会其内部的细节。这就是传说中的面向接口编程：P
对象都是可抽象的
对象有着许多个不同的方面。一般来说，对象参与一个场景时会展现出某一个方面。总可以将对象的某一个方面抽象出来，让其作为对象的一个代码来参与场景交互。通常这种抽象会以接口来命名。在分析过程中，得到的任何一个对象都有特定的方面可作为抽象。因为对象总是从场景分析中得到的，它在场景中肯定战象了一个方面。对象所具有的方面，或者说对象所参与的场景越多，对象越有抽象价值，反之则越没有抽象价值。因此在分析过程中，应当关注于那些参与了很多场景的对象，他们往往是分析设计中的重点以及成败关键。
对象都是有层次的
层次越高，其描述约粗略但适应能力越广；层次越低则描述越精确但适应能力越下降。在分析过程中，应当根据问题领域的复杂程度设定多个抽象层次，在每个层次上使用合适的抽象程度的对象描述。这将有助于显著的减少分析的难度和工作量。
不论是在需求、分析还是设计过程中，都应当具备抽象层次的观点。从需求到设计的过程已经是几个不同的抽象层次，笔者要说的是，在其中的一个阶段，例如需求阶段，仍然可以再多分几个抽象层次来说明。具体分多少抽象层次应视问题领域的复杂程度而定。
总结
独立性、原子性、抽象性和层次性是面向对象分析时应当遵循的一些原则和方法。在实际工作中，图2.5所示的几个方面是需要考虑的，如果该对象是一个关键对象，则应当尽量说明途中所示方面的内容。
