把书读薄之《面向对象葵花宝典》阅读笔记-面向对象实战

《面向对象葵花宝典》是网友爱技术的华仔的一个技术专栏里的文章，我在逐篇阅读之后，最大的感觉就是这个面向对象编程系列是货真价实的来自技术前线工程师的经验之作，是作者工作经验的总结和升华，对面向编程的方方面面有指导意义，在这里强烈推荐给面向对象领域的朋友们，原文链接如下：http://blog.csdn.net/column/details/oobaodian.html

以下是个人阅读之后，基于xMind做的读书笔记的整理，将我个人认为特别有价值或者说对我比较有感触的知识点，记录如下，以便随时翻阅。

面向对象实战

对象全流程概述

• 我们将瀑布模型、敏捷开发等称为“管理流程”

• 将面向对象开发流程称为“技术流程”

• 面向对象的技术流程可以概括如下: 需求模型 -> 领域模型 -> 设计模型 -> 实现模型

• 通过这种一步一个脚印的方式,即使是经验并不丰富的菜鸟,也能完成从需求到最后实现的相关工作,而不再需要仰望和崇拜其他大虾大牛,或者自己摸着石头过河了!

• 需求模型

  • 通过和客户沟通,结合行业经验和知识,明确要求客户的需求。

• 领域模型

  • 基于需求模型,提炼出领域相关的概念,为后面的面向对象设计打下基础。

• 设计模型

  • 以领域模型为基础,综合面向对象的各种设计技巧,完成类的设计。

• 实现模型

  • 以设计模型为基础,将设计模型翻译为具体的语言实现,完成编码。

需求模型

• 需求详解

  • 需求即系统需要做什么

  • 正是这个简单的定义,让很多人陷入了陷阱:需求即功能。

  • 需求:对客户来说有价值的事情;

  • 功能:系统为了实现客户价值而提供的能力;

  • 区别是需求还是功能的方法很简单了:只要判断是否对客户有价值。

• 需求的重要性

  • 很多项目都不怎么重视需求!

  • 据统计,有将近 1/3 的项目失败或者陷入困境时因为需求原因导致的!垃圾进垃圾出(Garbage in, garbage out)”

  • 修复需求错误的问题的成本非常高

• 需求分析目的

  • 客户会告诉我们他们的需求,但大部分情况都不会告诉你需求背后的问题。而需求分析的终极目的,就是要“挖掘客户的问题,实现客户价值”!

  • 深入了解客户的问题,有助于你更好的实现需求。

  • 一般来说,需求分析有三重境界,分为“记录员”“分析员”“引导员”三个级别

  • 要想做好需求分析,要时刻抓住“客户的问题和价值”这个指导思想!

• 需求分析的方法

  • 需求分析 518 方法

  • 5:5W,即 When、Where、Who、What、Why

  • 5W 作为一组,首先是它们都以 W 开头,但这不是最关键,最关键的在于这些是一个需求产生的环境,或者说上下文(英文 Context)。为什么我们要关注需求产生的环境?很简单:环境影响需求。 举个很简单的例子:同样是垃圾桶,放在巴西贫民窟的要求和放在纽约帝国大厦肯定不一样。

  • 1:1H,即 How 参见: 用例方法。 很多人常犯的一个错误是在需求分析阶段分析了需求如何实现,这样做是不正确的。需求分析阶段的 How不是指如何实现需求,而是指需求本身的流程,如何实现需求那是设计阶段的事情!

    • 在前面进行 5W 分析的时候,我们没有什么具体的指导方法,分析时主要靠分析人员的经验、水平,而How 则不一样,进行 How 分析时有一套成熟的方法,这就是“用例方法”!

  • 8:8C,即 8 个 Constraint,包括性能 Performance、成本 Cost、时间 Time、可靠性 Reliability、安全性Security、合规性 Compliance、技术性 Technology、兼容性 Compatibility

    • 前面的 5W+1H 是属于功能属性,而 8C 是属于质量属性

• 用例方法

  • 参见: 1:1H,即 How

  • “用例是用来描述需求的流程”,即:描述 5W1H 中的 How。

  • 用例方法三段法(NEA 方法)

    • 1) 正常处理(Normal):通过和客户沟通,分析需求的正常流程;

    • 2) 异常处理(Exception):在正常处理流程的步骤上,分析每一步的各种异常情况和对应的处理; “异常”是指流程的异常情况,而不包含系统本身的的异常。

    • 3) 替代处理(Alternative):在正常处理流程的步骤上,分析每一步是否有其它替代方法,以及替代方法如何做;

  • 用例的具体写法

    • 【用例名称】

    • 【场景】场景即用例发生的环境,正好对应 5W 中的 3 个 W:Who、Where、When

    • 【用例描述】描述详细的用例内容,对应 5W 中的 What 和 How,即用户应该怎样做,以及每个步骤中的输出。但并不要求每个步骤都一定有输出,可以有也可以没有,也可以有多个。

    • 【用例价值】描述用例对应的客户价值,对应 5W 中的 Why。

    • 【约束和限制】即整个需求流程中相关的约束和限制条件,对应 518 方法中的 8C。

  • 要画图么?

    • 必须是有了需求和用例之后,才有用例图,说白了,用例图是用例的图形化描述,但是它并不能取代用例。还有另外一个更重要的原因:用例是客户和公司关于产品的一个共同认识!一般情况下,市场人员和客户沟通交流,了解客户的需求,然后和客户一一确认,最后形成需求文档。在这个过程中,主要是客户和市场人员参与,而没有研发的人员参与。

• 功能

  • 有了用例之后,提取功能可以说是一个水到渠成的事情,基本上只是一个文字工作,我们只需要将用例中那些需要系统完成的事情——更简单的说:是动词——提取出来,就成为了系统的功能。

• 用例图的陷阱

  • 所谓用例图,可以简单的理解为系统用例的集合,而不是详细描述每个用例的具体步骤和流程。这也是前面我们提到的为什么是用“用例”来分析需求,而不是用“用例图”来分析需求的原因。

• SSD

  • “系统顺序图”,主要用于描述某个用例的某个分支场景下,外部参与者与系统的交互过程。简单来说:SSD 就是用例的可视化描述。

用例方法分析需求的时候,确实不需要图;但用例方法分析完成后得到的用例,我们可以使用 SSD 让用例更直观一些。

领域模型

• 领域模型定义如下:领域模型是对领域内的概念类或现实世界中对象的可视化表示,又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。

• 这个阶段真正开始面向对象的工作

• 领域建模三字经

  • 找名词 从需求模型中找,具体来说就是从用例中找。

  • 加属性 找出领域模型的名词后,接下来一个重要工作就是将这些名词相关的属性找出来,使其更加准确。但加属性和前面找名词有一点点差别:有的属性并没有在用例中明确给出,需要分析人员和设计人员额外添加,此时也是分析师的行业和领域经验起决定作用。

  • 连关系

设计模型

• 经过领域模型的分析后,面向对象已经初具雏形,但领域类并不能指导我们进行编码工作,因为领域类只是从用例模型中提炼出来的反应业务领域的概念,而并不是真正意义上的软件类。

• 是从用例模型中提炼出来的反应业务领域的概念,而并不是真正意义上的软件类。

• 设计模型主要包含 2 部分内容:静态模型、动态模型

• 静态模型又可以称为“类模型”,主要关注系统的“静态”结构,描述了系统包含的类, 以及类的名称、职责、属性、方法,类与类之间的关系。

• 第一步(照猫画虎):领域类映射

  • 领域模型中的“领域类”,是设计模型中“软件类”最好的来源。
  • 我们设计最初的“软件类”,具有如下几个明显的优点:
  • 1)软件类来自领域类,领域类来自用例,用例来自客户,这样一环扣一环,软件类的正确性得到了保证,不用担心拍脑袋带来的问题;
  • 2)领域类到软件类的转换非常简单,不需要天才的创新,或者丰富的想象力,只要掌握基本的面向对象的知识就能完成,菜鸟也能做设计;

  • 3)不需要参考其它系统,不用担心没有参照物时无法设计的问题;

  • 【类筛选】

  • 【名称映射】

  • 【属性映射】

  • 【提炼方法】

  • 从用例模型找动词

    • 【筛选】

    • 【提炼】

    • 【分配】

• 第二步(精雕细琢):应用设计原则和设计模式

  • 【设计原则】SOLID

    • 单一职责原则

    • 开放/封闭原则

    • Liskov 替换原则

    • 接口隔离原则

    • 依赖反转原则

    • 我们都可以依次使用设计原则进行判断,当发现不符合设计原则的设计时,就采取增加、删除、合并、拆分等手段,使我们的设计逐步改进,最终达到符合设计原则的目的。

  • 设计模式

    • "四人帮"

    • 计原则和设计模式并不是竞争关系,正好相反,它们是互补的关系。设计原则和设计模式互补体现在:设计原则主要用于指导“类的定义”的设计,而设计模式主要用于指导“类的行为”的设计,更通俗一点的讲:设计原则是类的静态设计原则,设计模式是类的动态设计原则。 一般情况下,我们是采用“先设计原则,后设计模式”的方法来操作的。

• 第三步(照本宣科):拆分辅助类

  • 拆分辅助类的主要目的是为了使我们的类在编码的时候能够满足一些框架或者规范的要求。比如说常见的MVC 模式,将一个业务拆分成 Control、Model、View 三个元素;

• 动态模型关注系统的“动态”行为,描述类本身的一些动作或者状态变化,以及类之间如何配合以完成最终的业务功能。

  • 动态模型设计一般都是在类模型设计完成后才开始,因为动态模型设计的时候一般都需要用到类模型中的类。相对类模型来说,动态模型要相对简单一些,主要原因在于动态模型设计的时候没有什么设计原则和设计模式需要应用,只需要对照用例模型,根据用例模型的特点,选取一个合适的动态模型将其表述出来即可。

  • 【状态模型】

    • 状态模型主要用于描述对象的生命周期的状态变化。通过状态图,我们可以了解到对象有哪些状态,状态之间如何转换,转换的触发条件等。当我们发现一个对象的状态比较复杂的时候,就需要设计对象的状态模型。

  • 【活动模型】

    • 活动模型主要用于描述一个工作流程或者计算流程。其关注点是在完成某项工作的过程中,系统中的哪些对象承担了什么样的任务、做了什么处理,以及这些对象之间的先后交互关系。当我们发现一个处理流程比较复杂的时候,就需要设计流程的活动模型。

  • 【序列模型】

    • 序列模型主要用于描述对象按照时间顺序组织的消息交互过程,其关键特征是强调按照“时间顺序”来组织对象的交互,所以序列图有时又称为“时序图”或者“顺序图”。序列模型是我们最常用的动态模型,特别适合将用例模型或者 SSD 转换为系统的动态模型。

  • 【协作模型】

    • 协作模型主要用于描述按照对象之间的关联来组织的消息交互过程,其关键特征是强调“对象关系”来组织对象的交互。协作模型的作用和序列模型一样,只是强调的点不同,大部分的时候我们都是选择“序列模型”,因为序列模型的时间顺序很多时候和用例模型的步骤不谋而合。

• 面向对象设计并不是什么高深的技术,也不需要天才的创新,更不需要变魔法,而是有章可循的,只要我们按照一定的步骤,一步一个脚印,不断精益求精,就能够完成面向对象的设计。

实现模型

• c++

• java