目录
分类
正确分类的重要性
分类的困难
分类的增量和迭代本质
确定类和对象
经典方法 && 现代方法 (种)
面向对象分析 (主要识别对象)
关键抽象和机制
确定关键抽象
识别机制
面向对象的分析与设计的难点
分类
- 组织知识的手段。
- 【作用】相似性 共性 关键抽象 更小的应用,更简单的架构。
- 【Question】
- 分类在类的构建中发挥了什么样的作用? (结合具体示例加以体会)
正确分类的重要性
- 在面向对象分析和设计中,相当一大部分活动,可以认为是分类问题。
- 在AI中,分类也是及其重要的,是很多训练的最终目的。
- 分类的关键环节: 发现共性。
- 找出 结构/行为 存在共性的一组事物
- 【分类在面向对象中的作用体现】 分类作用很大
- 【帮助我们确定层次结构】如类之间的泛化、特化、聚合等等。
- 【核心机制的产生】交互中的共同模式 发明机制 核心
- 【模块化】根据类对象的功能分包,进行模块化。
- 【耦合&内聚】
- 【部署】将不同的处理过程分配到不同的处理器上。
分类的困难
前面提到了分类 在面向对象中发挥着十分重要的作用。(可以说,是一种非常基础的能力)。事实上,在数据排查时,也是如此。
- 【造成分类困难的原因】
- 【边界的模糊】一种常见的现象时,一个对象和其它对象区分开来的边界,往往非常模糊。
- 【示例】如膝盖从哪里开始,从哪里结束?
- 【人的角度】
- 分类的角度多种多样,不存在“完美”的分类。 我们需要权衡不同的分类方案。
- 如 flink虽然在目前比较流行/优秀,但随着技术的迭代,新的角度的发现,flink有一天也会被相应的淘汰。
- 明智的分类需要大量的创造性的活动。
- 分类的角度多种多样,不存在“完美”的分类。 我们需要权衡不同的分类方案。
- 【边界的模糊】一种常见的现象时,一个对象和其它对象区分开来的边界,往往非常模糊。
- 【分类需要投入较多的精力】
- 很多艰苦的工作,才能设计出简单的架构。
分类的增量和迭代本质
- 【一般规律】明智的分类 是 很艰难的智力工作,最好是一个增量式、迭代式的过程来完成。
- 如 flink虽然在目前比较流行/优秀,但随着技术的迭代,新的角度的发现,flink有一天也会被相应的淘汰。
确定类和对象
经典方法 && 现代方法 (3种)
经典分类
- 【核心】根据相关属性作为对象间相似性 分类的依据。
经典分类的属性选择:
- 【选择分类属性时的建议】 属性之间最好是独立的,不相互影响的。
- 【反例】年龄 和班级 就是关联性相对较大的属性。
- 【属性可测量可不测量】
- 【属性的选择和领域高度相关】
自然分类的缺陷:
- 自然的分类趋向混乱。
概念聚集
- 借助概念,来将符合概念的纳入相应的分类中。
- 【分类的大致步骤】
- 形成某个类的概念描述 根据描述,对于实体进行分类。
- 【示例】爱情歌曲
- 【概念描述】表达一个人对于另一个人的爱。
- 爱,这个词是抽象的,是模糊的,这和个人的理解也有一定的关系。
- 【对于实体歌曲的分类】
- 【爱情歌曲】一首歌,描绘两个异性动物之间的快乐生活。 要体会到其深层次的比喻的含义。
- 【非爱情歌曲】国歌。 主题不能反映两人之间相爱。
- 【概念描述】表达一个人对于另一个人的爱。
原型理论
- 【分类方式】
- 【原型代表】对象的类 由一个 原型对象 代表;
- 【与原型进行比对】对于给定的对象,和原型进行比较,如果相似 该对象属于原型所代表的类。
- 【实际中的应用】
- 论文中,为验证观点,做个简单的原型。用以表明论文中涉及到的关键点。
- Js 中的原型链。 对象模板。
- 对于游戏的归类。
面向对象分析 (主要识别对象)
经典方法 (主要用来识别对象)
建模时,类和对象的一般来源:
- 【经典方法】是在大量经验基础上,对于建模中存在的模式进行了相应的总结。 形成了某些概念/事物 到 对象的映射。
- 一种可以直接拿来,偷懒的分类框架。
数据库建模的角度,来看:
其它:
行为分析
- 【基本思想】将行为 作为 分类的重要依据,作为 识别 类和对象的主要来源。
- 【分类内核】概念聚集 (前面3种分类方法中的第2种)
- 通过概念描述出一个类 然后将符合该概念的实体,划分到该分类中来。
- 站在此处来看,分类需要一定的语言学功底。
领域分析
- 区分:问题域 & 解决方案域
用例分析
其它方法略过 。。。
关键抽象和机制
【关键抽象】
- 【有不同的身份】类/对象 , 问题域词汇表的一部分。
- 【重要作用】给出了 问题的边界。
- 关键抽象描绘了,哪些在关键抽象范围内,哪些在其外。
- 突出系统中的一些事物
- 排除系统之外的事物
【机制】
- 机制代表行为模式。
确定关键抽象
- 【具体问题具体对待】 关键抽象 与 具体领域高度相关。
- 【关键抽象的两个过程】
- 【发现】
- 抽象领域专家所使用的抽象;
- 往往是 问题域 的词汇的一部分。
- 【示例】ATM客户提到的账户、取款 & 存款
- 【发明】
- 通过发明,创造新的类 和对象。 它们不一定是问题域的组成部分,可能是设计/实现 领域的 词汇。
- 【示例】ATM中的关键词汇:数据库,屏幕管理器,队列等。 这部分更多是站在实现角度来确定关键抽象的。
- 【发现】
精化关键抽象:
- 选定关键抽象之后,我们应该在此抽象上做哪些事情?
- 一个抽象的概念,是无法 直接落地到的实现的。我们需要通过细化抽象,使得抽象层次越来越接近落地/实现。
- 【一些具体的问题】 概念/抽象 一 开始并不是‘清晰’的,通过回答下面一些参考的问题,能够让一些边界清晰起来。
- 对象如何创建?销毁?
- 在此对象上,可以执行什么操作?
- …
- 【关于对象抽象活动的观点】
- 面向对象设计 是 增量的,迭代的。
- 【常见的活动模式】
- 从两个类中,提取公共部分到一个新类中。
- 将一个类,分成两个新类。
- 【注意】既不是自顶向下,也不是自底向上 的活动。 而是两者的有机结合。
将类和对象放在正确的抽象层次很难。
- 需要进行大量练习,积累足够的经验。
【命名抽象】
一般建议:
识别机制
一个简单的示例:
- 【外部视图】驾驶员看到的是外部视图,也就是汽车系统表现出的外部行为;
- 【内部视图】但是,外部视图/行为,是需要内部的机制来进行支撑的。
- 【哪种活动的结果?】设计时的结果
- 【支撑外部视图的内部机制有多种】达到支撑一个外部行为的方式有多种,我们需要从中进行选择/决策。 上面提到的汽车系统,内部机制就存在很多种。
- 【机制的选择】虽然不同机制表现出来的外部行为是等价的,但是在其它方面是存在差异的,比如说代价等。
在进行机制选择时,需要考虑的问题:
避免内外违反约定:
- 机制代表战略决策,接口的设计 体现了战术决策。
- 【外部违反】客户违反规定的接口;
- 【内部违反】接口背后的机制 违反了 该规定的行为;
- 【如何进行机制的分析?】
- 使用场景 驱动机制分析过程;
- 【NICE】研究 典型/关键的场景,很重要。
- 使用场景 驱动机制分析过程;
- 【协作模式】
- 开发者决定采用某种协作模式 工作分解到多个对象(相应类的方法)
- 【示例】MVC可以看作是一种 模式/机制,属于战略层面。
机制即模式
- 【我的理解(可能有误)】模式,感觉 是一些在探索过程中,普遍被认可的机制。
- 【机制在底层的表现:食物链的底端】惯用法
- 每个编程语言 有自己的惯用法;
- 许多常见的编程任务都用惯用的实现方式;
- 【框架:食物链的高端】
- 【框架介绍】一组类,为某个领域提供了一组服务。 代表了大规模的复用;
- 【作用】输出了一些类和机制 客户可以使用/扩展 它们;
机制的示例(画图机制):【MVC】
- 【画图机制】 几个对象通过协作(内部视图) 为用户展现图片(外部视图)。
- 【对象】窗口、视图、模型、客户
- 【流程】 见下面的文字。
- 【该机制的好处】
- 模型 与 窗口/视图 解耦. 这样解耦之后有何好处? (方便修改、维护)
面向对象的分析与设计的难点
这类问题可以归结为,在方案空间中,选择较好的解的问题。
- 【抽象】抽象的方式多种多样?
- 【连接方式】组合对象的方式多种多样?
- 【语义】表达是否有助于理解?是否能够涌现出需要的功能?
- 单纯看代码,不了解其面向的业务,是不太容易读懂代码的。