- 本书是帮助开发者和学生学习面向对象分析和设计（OOA/D）的核心技能的重要工具。
- UML不是OOA/D，也不是方法，只是图形表示法，如果没有真正掌握如何创建优秀的面向对象设计，或者如何评估和改进现有设计，那么学习UML或者UML CASE工具是毫无意义的。对象思想才是重点和难点。
- 在OO开发中，至关重要的能力是熟练地为软件对象分配职责，除此之外当然还有其他很多重要的技能。
- 有益的分析和设计可以概括为：做正确的事（分析）和正确地做事（设计）。
- 面向对象分析的过程中强调在问题领域内发现和描述对象（或概念）。面向对象设计过程中强调定义软件对象及它们如何协作以实现需求。
- 如果不具备良好的OO设计和编程技能，那么即使使用UML，也只能画出拙劣的设计。
- 你应该只在想取得成功的项目上实施迭代开发。
- 迭代和进化式开发抱以接受变更与改写的态度，并以此为真正本质的驱动力。
- 个体和迭代，超越过程和工具；工作的软件，超越完整的文档；客户协作，超越合同谈判；相应变更，超越履行计划。——敏捷宣言
- UP的四个阶段——初始、细化、构造、移交——绝对不是顺序关系，嗯，实际上它们是相互渗透的。
- 初始阶段的目标并不是定义所有需求，而是从总体上评估项目是否继续，如何继续。
- 如果发现自己在所谓的UP或迭代项目中，试图在开始编程和测试之前制定大多数或所有需求（用例等），则意味着没有正确理解UP。
- 用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。
- 有助于发现有用用例的三种测试：老板测试、EBP（基本业务过程）测试、规模测试。
- 生成用例/需求是迭代的。
- 在多个迭代里对同一用例进行增量式开发。
- 细化阶段：构建核心架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。
- 领域层软件类的名称要源于领域模型中的名称，以使对象具有源于领域的信息和职责。这可以减小我们的思维与软件模型之间的表示诧异。
- 如果我们某概念X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。
- 以迭代的方式做正确的事，正确地做事。
- 尽早引发变更。
- UML初学者一般会认为静态视图的类图是重要图形，但事实上，大部分具有挑战性、有益和有效的设计工作都会在绘制UML动态视图的交互图的时候发生。
- 对象设计技能比UML表示法技能更重要。
- 基于职责设计对象。
- 最关键的软件开发工具是受过良好设计原则训练的思维，而不是UML或仍和其他技术。
- 思考软件对象设计以及大型构件的流行方式是，考虑其职责、角色和写作。这是被称为职责驱动设计（RDD）的大型方法的一部分。
- 模式是重要的，但另一方面，它只是原则进行结构化和命名的一种学习工具，一旦掌握了这些基本原则，特定的模式术语就不是那么重要了。
- 学习GRASP和基本GoF模式是本书的关键目标。
- GRASP定义了9个基本OO设计原则或基本设计构件：创建者、信息专家、低耦合、高内聚、控制器、高内聚、多态、间接性、纯虚构、防止变异。
- 创建者：如果以下条件之一为真，将创建类A实例的职责分配给类B：
? B“包含”或组成聚集A
? B记录A
? B直接使用A
? B具有A的初始化数据，并且创建A时会将这些数据传递给A
- 信息专家：把职责分配给信息专家，它具有实现这个职责所必须的信息。见上一模式中最后一种情况，B是专家。
- 低耦合：分配职责，使耦合性尽可能低。利用这一原则来评估可选方案。
- 控制器：UI层之上的第一个对象（区别于MVC中的C），它负责接受和处理系统操作消息。把职责分配给能代表以下选择之一的类：
? 1）代表整个系统、根对象、运行软件的设备或主要子系统，这些是外观控制器的所有变体
?2）代表用例场景，在该场景中发生系统时间，通常命名为UseCaseNameHandler、UseCaseNameCoordinator或UseCaseNameSession
? 对于同一用例场景的所有系统事件使用相同的控制器类
? 通俗地说，会话是与参与者进行交谈的实例。会话可以具有任意长度，但通常按照用例来组织
- 高内聚：分配职责可保持较高的内举行。可利用这一点来评估候选方案。
内聚性较低的类要做许多互不相关的工作，或需要完成大量的工作。这样的类是不合理的，它会导致以下问题：
? 1）难以理解
? 2）难以服用
? 3）难以维护
? 4）脆弱，经常会受到变化的影响
内聚性低的类通常表示大粒度的抽象，或承担了本应委托给其他对象的职责
- 不良耦合与不良内聚通常携手同行。
- 所有的交互都会趋于产生不良耦合。
- 过低的耦合也是不良的表现。
- 高耦合对于稳定和普遍使用的元素而言并不是问题。高耦合本身并不是问题所在，问题是与某些不稳定的元素之间的高耦合。
- 作为设计者，我们可以增加灵活性，封装细节和实现，以及在系统众多方面降低耦合的一般设计。但如果我们把精力放到“未来验证”的或没有实际理由的低耦合设计上，则所花费的时间并不值得。
- 耦合与内聚是真正的基本原则，应当受到重视，并为所有软件开发者所应用。
- 少数情况下可以接受低内聚：将一组职责或代码放入一个类或构件中，以使某个人能方便的对其进行维护；另一种情况是具有分布式服务器对象的低内聚构件。
- 多态：当相关选择或行为随类型有所不同时，使用多态操作为变化的行为类型分配职责。不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。
- 纯虚构：对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念——虚构的事物，用以支持高内聚、低耦合和复用。这种类是凭空虚构的，纯虚构一词的含义是——当我们穷途末路时所捏造的某物。
- 间接性：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其他构件之间的间接性。
- 防止变异：识别预计变化或不稳定支出，分配职责用以在这些变化之外创建稳定接口。这里的接口指的是广泛以上的访问视图，而不仅仅是诸如Java接口等字面含义。
- 防止变异（PV）是一个根本原则，其促成了大部分编程和设计额的机制和模式，用来提供灵活性和防止变化——这些变化包括数据、行为、硬件、软件构件、操作系统等中的变化。
- 数据封装、接口、多态、间接性和标准都是源于防止变异（PV）的。诸如虚拟机和操作系统等构件是实现PV的间接性的复杂例子。
- 不要和陌生人讲话（得墨忒尔定律）：在方法里只应该给以下对象发送消息：
1) this对象
2) 方法的参数
3) this的属性
4) 作为this属性的集合中的元素
5) 在方法中创建的对象
- 对变化点（现有、当前系统或需求中的变化）和进化点（预测将来可能会产生的变化点但不存在于现有需求中）都可以应用变更，当应用此原则时要小心，请看下一条。
- 初学者倾向于脆弱的设计，中等程度的开发者则倾向于过度想象的、灵活的、一般化的设计（从来都不会得到实用）。专家级的开发者会理智地进行选择；有时，简单和脆弱的设计可能与其变化所需的成本达成平衡。
- 信息隐藏：这不是数据封装的思想，它是指——由于困难和可能的变化而对其他模块隐藏与设计相关的信息。
- 开放—封闭原则（OCP）：模块应该同时（对扩展、可适应性）开放和（对影响客户的更改）封闭。该原则基本上等价于防止变异（PV）模式和信息隐藏。
- GoF模式，多阅读经典之作《设计模式——可复用面向对象软件的基础》，并在实践中应用该书中描述的23种模式。
- 模式不仅仅可以运用于设计类及其协作，在系统架构上同样适用。使用模式设计的具有永久性的框架复用度更高。
时间： 2024-12-31 03:39:50