《UML和模式应用》重点之思想篇

1. 本书是帮助开发人员和学生学习面向对象分析和设计（OOA/D）的核心技能的重要工具。

2. UML不是OOA/D。也不是方法，仅仅是图形表示法，假设没有真正掌握怎样创建优秀的面向对象设计，或者怎样评估和改进现有设计，那么学习UML或者UML CASE工具是毫无意义的。对象思想才是重点和难点。
3. 在OO开发中，至关重要的能力是熟练地为软件对象分配职责。除此之外当然还有其它非常多重要的技能。
4. 故意的分析和设计能够概括为：做正确的事（分析）和正确地做事（设计）。
5. 面向对象分析的过程中强调在问题领域内发现和描写叙述对象（或概念）。面向对象设计过程中强调定义软件对象及它们怎样协作以实现需求。
6. 假设不具备良好的OO设计和编程技能，那么即使使用UML，也仅仅能画出拙劣的设计。
7. 你应该仅仅在想取得成功的项目上实施迭代开发。
8. 迭代和进化式开发抱以接受变更与改写的态度。并以此为真正本质的驱动力。
9. 个体和迭代，超越过程和工具；工作的软件。超越完整的文档；客户协作，超越合同谈判。对应变更，超越履行计划。

   ——敏捷宣言

10. UP的四个阶段——初始、细化、构造、移交——绝对不是顺序关系，嗯。实际上它们是相互渗透的。
11. 初始阶段的目标并非定义全部需求。而是从整体上评估项目是否继续。怎样继续。

12. 假设发现自己在所谓的UP或迭代项目中，试图在開始编程和測试之前制定大多数或全部需求（用例等），则意味着没有正确理解UP。

13. 用例是文本文档。而非图形；用例建模主要是编写文本的活动。而非制图。
14. 有助于发现实用用例的三种測试：老板測试、EBP（基本业务过程）測试、规模測试。

15. 生成用例/需求是迭代的。

16. 在多个迭代里对同一用例进行增量式开发。
17. 细化阶段：构建核心架构，解决高风险元素，定义大部分需求。以及估计整体进度和资源。

18. 领域层软件类的名称要源于领域模型中的名称，以使对象具有源于领域的信息和职责。

    这能够减小我们的思维与软件模型之间的表示诧异。

19. 假设我们某概念X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。
20. 以迭代的方式做正确的事。正确地做事。
21. 尽早引发变更。
22. UML刚開始学习的人通常会觉得静态视图的类图是重要图形，但其实，大部分具有挑战性、故意和有效的设计工作都会在绘制UML动态视图的交互图的时候发生。

23. 对象设计技能比UML表示法技能更重要。
24. 基于职责设计对象。
25. 最关键的软件开发工具是受过良好设计原则训练的思维。而不是UML或仍和其它技术。
26. 思考软件对象设计以及大型构件的流行方式是，考虑其职责、角色和写作。这是被称为职责驱动设计（RDD）的大型方法的一部分。
27. 模式是重要的，但还有一方面，它仅仅是原则进行结构化和命名的一种学习工具，一旦掌握了这些基本原则。特定的模式术语就不是那么重要了。
28. 学习GRASP和基本GoF模式是本书的关键目标。
29. GRASP定义了9个基本OO设计原则或基本设计构件：创建者、信息专家、低耦合、高内聚、控制器、高内聚、多态、间接性、纯虚构、防止变异。

30. 创建者：假设下面条件之中的一个为真，将创建类A实例的职责分配给类B：
    
     B“包括”或组成聚集A
    
     B记录A
    
     B直接使用A
    
     B具有A的初始化数据。而且创建A时会将这些数据传递给A
31. 信息专家：把职责分配给信息专家。它具有实现这个职责所必须的信息。见上一模式中最后一种情况。B是专家。
32. 低耦合：分配职责。使耦合性尽可能低。利用这一原则来评估可选方案。
33. 控制器：UI层之上的第一个对象（差别于MVC中的C），它负责接受和处理系统操作消息。把职责分配给能代表下面选择之中的一个的类：
    
     1）代表整个系统、根对象、执行软件的设备或主要子系统，这些是外观控制器的全部变体
    
    2）代表用例场景，在该场景中发生系统时间。通常命名为UseCaseNameHandler、UseCaseNameCoordinator或UseCaseNameSession
    
     对于同一用例场景的全部系统事件使用相同的控制器类
    
     通俗地说。会话是与參与者进行交谈的实例。会话能够具有随意长度，但通常依照用例来组织
34. 高内聚：分配职责可保持较高的内举行。可利用这一点来评估候选方案。
    
    内聚性较低的类要做很多互不相关的工作，或须要完毕大量的工作。这种类是不合理的。它会导致下面问题：
    
     1）难以理解
    
     2）难以服用
    
     3）难以维护
    
     4）脆弱，常常会受到变化的影响
    
    内聚性低的类通常表示大粒度的抽象，或承担了本应托付给其它对象的职责
35. 不良耦合与不良内聚通常携手同行。
36. 全部的交互都会趋于产生不良耦合。
37. 过低的耦合也是不良的表现。
38. 高耦合对于稳定和普遍使用的元素而言并非问题。

    高耦合本身并非问题所在，问题是与某些不稳定的元素之间的高耦合。

39. 作为设计者，我们能够添加灵活性，封装细节和实现。以及在系统众多方面减少耦合的一般设计。但假设我们把精力放到“未来验证”的或没有实际理由的低耦合设计上。则所花费的时间并不值得。

40. 耦合与内聚是真正的基本原则。应当受到重视，并为全部软件开发人员所应用。
41. 少数情况下能够接受低内聚：将一组职责或代码放入一个类或构件中，以使某个人能方便的对其进行维护。还有一种情况是具有分布式server对象的低内聚构件。

42. 多态：当相关选择或行为随类型有所不同一时候，使用多态操作为变化的行为类型分配职责。

    不要測试对象的类型。也不要使用条件逻辑来执行基于类型的不同选择。

43. 纯虚构：对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念——虚构的事物，用以支持高内聚、低耦合和复用。这种类是凭空虚构的，纯虚构一词的含义是——当我们穷途末路时所捏造的某物。
44. 间接性：将职责分配给中介对象，使其作为其它构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其它构件之间的间接性。
45. 防止变异：识别估计变化或不稳定支出，分配职责用以在这些变化之外创建稳定接口。

    这里的接口指的是广泛以上的訪问视图。而不仅仅是诸如Java接口等字面含义。

46. 防止变异（PV）是一个根本原则，其促成了大部分编程和设计额的机制和模式。用来提供灵活性和防止变化——这些变化包括数据、行为、硬件、软件构件、操作系统等中的变化。
47. 数据封装、接口、多态、间接性和标准都是源于防止变异（PV）的。诸如虚拟机和操作系统等构件是实现PV的间接性的复杂样例。
48. 不要和陌生人讲话（得墨忒尔定律）：在方法里仅仅应该给下面对象发送消息：
    
    1) this对象
    
    2) 方法的參数
    
    3) this的属性
    
    4) 作为this属性的集合中的元素
    
    5) 在方法中创建的对象
49. 对变化点（现有、当前系统或需求中的变化）和进化点（预測将来可能会产生的变化点但不存在于现有需求中）都能够应用变更。当应用此原则时要小心。请看下一条。

50. 刚開始学习的人倾向于脆弱的设计。中等程度的开发人员则倾向于过度想象的、灵活的、一般化的设计（从来都不会得到实用）。专家级的开发人员会理智地进行选择；有时，简单和脆弱的设计可能与其变化所需的成本达成平衡。
51. 信息隐藏：这不是数据封装的思想，它是指——因为困难和可能的变化而对其它模块隐藏与设计相关的信息。
52. 开放—封闭原则（OCP）：模块应该同一时候（对扩展、可适应性）开放和（对影响客户的更改）封闭。该原则基本上等价于防止变异（PV）模式和信息隐藏。
53. GoF模式，多阅读经典之作《设计模式——可复用面向对象软件的基础》，并在实践中应用该书中描写叙述的23种模式。

54. 模式不仅仅能够运用于设计类及其协作，在系统架构上相同适用。

    使用模式设计的具有永久性的框架复用度更高。

$(function () {
$('pre.prettyprint code').each(function () {
var lines = $(this).text().split('\n').length;
var $numbering = $('

').addClass('pre-numbering').hide();
$(this).addClass('has-numbering').parent().append($numbering);
for (i = 1; i ').text(i));
};
$numbering.fadeIn(1700);
});
});