《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. 模式不仅仅能够运用于设计类及其协作,在系统架构上相同适用。

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

posted @ 2016-02-23 14:52  mengfanrong  阅读(2045)  评论(0编辑  收藏