目录

分类

正确分类的重要性

分类的困难

分类的增量和迭代本质

确定类和对象

经典方法 && 现代方法 （种）

面向对象分析 （主要识别对象）

关键抽象和机制

确定关键抽象

识别机制

面向对象的分析与设计的难点

分类

• 组织知识的手段。
• 【作用】相似性 共性 关键抽象 更小的应用，更简单的架构。
• 【Question】
  • 分类在类的构建中发挥了什么样的作用？ （结合具体示例加以体会）

正确分类的重要性

• 在面向对象分析和设计中，相当一大部分活动，可以认为是分类问题。
  • 在AI中，分类也是及其重要的，是很多训练的最终目的。
• 分类的关键环节： 发现共性。
  • 找出 结构/行为 存在共性的一组事物
• 【分类在面向对象中的作用体现】 分类作用很大
  • 【帮助我们确定层次结构】如类之间的泛化、特化、聚合等等。
  • 【核心机制的产生】交互中的共同模式 发明机制 核心
  • 【模块化】根据类对象的功能分包，进行模块化。
  • 【耦合&内聚】
  • 【部署】将不同的处理过程分配到不同的处理器上。

分类的困难

前面提到了分类 在面向对象中发挥着十分重要的作用。（可以说，是一种非常基础的能力）。事实上，在数据排查时，也是如此。

• 【造成分类困难的原因】
  • 【边界的模糊】一种常见的现象时，一个对象和其它对象区分开来的边界，往往非常模糊。
    • 【示例】如膝盖从哪里开始，从哪里结束？
  • 【人的角度】
    • 分类的角度多种多样，不存在“完美”的分类。 我们需要权衡不同的分类方案。
      • 如 flink虽然在目前比较流行/优秀，但随着技术的迭代，新的角度的发现，flink有一天也会被相应的淘汰。
    • 明智的分类需要大量的创造性的活动。
• 【分类需要投入较多的精力】
  • 很多艰苦的工作，才能设计出简单的架构。

分类的增量和迭代本质

• 【一般规律】明智的分类 是 很艰难的智力工作，最好是一个增量式、迭代式的过程来完成。
  • 如 flink虽然在目前比较流行/优秀，但随着技术的迭代，新的角度的发现，flink有一天也会被相应的淘汰。

确定类和对象

经典方法 && 现代方法 （3种）

经典分类

• 【核心】根据相关属性作为对象间相似性 分类的依据。

经典分类的属性选择：

• 【选择分类属性时的建议】 属性之间最好是独立的，不相互影响的。
  • 【反例】年龄 和班级 就是关联性相对较大的属性。
• 【属性可测量可不测量】
• 【属性的选择和领域高度相关】

自然分类的缺陷：

• 自然的分类趋向混乱。

概念聚集

• 借助概念，来将符合概念的纳入相应的分类中。
• 【分类的大致步骤】
  • 形成某个类的概念描述 根据描述，对于实体进行分类。
• 【示例】爱情歌曲
  • 【概念描述】表达一个人对于另一个人的爱。
    • 爱，这个词是抽象的，是模糊的，这和个人的理解也有一定的关系。
  • 【对于实体歌曲的分类】
    • 【爱情歌曲】一首歌，描绘两个异性动物之间的快乐生活。 要体会到其深层次的比喻的含义。
    • 【非爱情歌曲】国歌。 主题不能反映两人之间相爱。

原型理论

• 【分类方式】
  • 【原型代表】对象的类 由一个 原型对象 代表；
  • 【与原型进行比对】对于给定的对象，和原型进行比较，如果相似 该对象属于原型所代表的类。
• 【实际中的应用】
  • 论文中，为验证观点，做个简单的原型。用以表明论文中涉及到的关键点。
  • Js 中的原型链。 对象模板。
  • 对于游戏的归类。

面向对象分析 （主要识别对象）

经典方法 （主要用来识别对象）

建模时，类和对象的一般来源：

• 【经典方法】是在大量经验基础上，对于建模中存在的模式进行了相应的总结。 形成了某些概念/事物 到 对象的映射。
  • 一种可以直接拿来，偷懒的分类框架。

数据库建模的角度，来看：

其它：

行为分析

• 【基本思想】将行为 作为 分类的重要依据，作为 识别 类和对象的主要来源。
• 【分类内核】概念聚集 （前面3种分类方法中的第2种）
  • 通过概念描述出一个类 然后将符合该概念的实体，划分到该分类中来。
  • 站在此处来看，分类需要一定的语言学功底。

领域分析

• 区分：问题域 & 解决方案域

用例分析

其它方法略过 。。。

关键抽象和机制

【关键抽象】

• 【有不同的身份】类/对象 ， 问题域词汇表的一部分。
• 【重要作用】给出了 问题的边界。
  • 关键抽象描绘了，哪些在关键抽象范围内，哪些在其外。
  • 突出系统中的一些事物
  • 排除系统之外的事物

【机制】

• 机制代表行为模式。

确定关键抽象

• 【具体问题具体对待】 关键抽象 与 具体领域高度相关。
• 【关键抽象的两个过程】
  • 【发现】
    • 抽象领域专家所使用的抽象；
    • 往往是 问题域 的词汇的一部分。
    • 【示例】ATM客户提到的账户、取款 & 存款
  • 【发明】
    • 通过发明，创造新的类 和对象。 它们不一定是问题域的组成部分，可能是设计/实现 领域的 词汇。
    • 【示例】ATM中的关键词汇：数据库，屏幕管理器，队列等。 这部分更多是站在实现角度来确定关键抽象的。

精化关键抽象：

• 选定关键抽象之后，我们应该在此抽象上做哪些事情？
  • 一个抽象的概念，是无法 直接落地到的实现的。我们需要通过细化抽象，使得抽象层次越来越接近落地/实现。
  • 【一些具体的问题】 概念/抽象 一 开始并不是‘清晰’的，通过回答下面一些参考的问题，能够让一些边界清晰起来。
    • 对象如何创建？销毁？
    • 在此对象上，可以执行什么操作？
    • …
• 【关于对象抽象活动的观点】
  • 面向对象设计 是 增量的，迭代的。
  • 【常见的活动模式】
    • 从两个类中，提取公共部分到一个新类中。
    • 将一个类，分成两个新类。
  • 【注意】既不是自顶向下，也不是自底向上 的活动。 而是两者的有机结合。

将类和对象放在正确的抽象层次很难。

• 需要进行大量练习，积累足够的经验。

【命名抽象】

一般建议：

识别机制

一个简单的示例：

• 【外部视图】驾驶员看到的是外部视图，也就是汽车系统表现出的外部行为；
• 【内部视图】但是，外部视图/行为，是需要内部的机制来进行支撑的。
  • 【哪种活动的结果？】设计时的结果
  • 【支撑外部视图的内部机制有多种】达到支撑一个外部行为的方式有多种，我们需要从中进行选择/决策。 上面提到的汽车系统，内部机制就存在很多种。
  • 【机制的选择】虽然不同机制表现出来的外部行为是等价的，但是在其它方面是存在差异的，比如说代价等。

在进行机制选择时，需要考虑的问题：

避免内外违反约定：

• 机制代表战略决策，接口的设计 体现了战术决策。
• 【外部违反】客户违反规定的接口；
• 【内部违反】接口背后的机制 违反了 该规定的行为；
• 【如何进行机制的分析？】
  • 使用场景 驱动机制分析过程；
    • 【NICE】研究 典型/关键的场景，很重要。
• 【协作模式】
  • 开发者决定采用某种协作模式 工作分解到多个对象（相应类的方法）
  • 【示例】MVC可以看作是一种 模式/机制，属于战略层面。

机制即模式

• 【我的理解（可能有误）】模式，感觉 是一些在探索过程中，普遍被认可的机制。
• 【机制在底层的表现：食物链的底端】惯用法
  • 每个编程语言 有自己的惯用法；
  • 许多常见的编程任务都用惯用的实现方式；
• 【框架：食物链的高端】
  • 【框架介绍】一组类，为某个领域提供了一组服务。 代表了大规模的复用；
  • 【作用】输出了一些类和机制 客户可以使用/扩展 它们；

机制的示例（画图机制）：【MVC】

• 【画图机制】 几个对象通过协作（内部视图） 为用户展现图片（外部视图）。
  • 【对象】窗口、视图、模型、客户
• 【流程】 见下面的文字。
• 【该机制的好处】
  • 模型 与 窗口/视图 解耦. 这样解耦之后有何好处？ （方便修改、维护）

面向对象的分析与设计的难点

这类问题可以归结为，在方案空间中，选择较好的解的问题。

• 【抽象】抽象的方式多种多样？
• 【连接方式】组合对象的方式多种多样？
• 【语义】表达是否有助于理解？是否能够涌现出需要的功能？
  • 单纯看代码，不了解其面向的业务，是不太容易读懂代码的。