OOA/D 01

时间:2022-03-23 01:56:31

建筑师一般不会为一栋100层的楼添加一个新的地下室,因为成本太高无疑会失败,但软件系统里提出类似改动需求时,他们通常都不会多想一下,相反他们会说:这只是一个简单的编程问题

可总会有一些看似极难完成、但却是市场所需的的需求,它可能会让你感觉需要推倒重来,这是我们不得不面对的问题

如果我们能在建造之初就预料到以后的地下室需求,或者对以后未知的需求有丰富的扩展体系,比如,按照对建筑行业的通用认知,建造时先挖个3层高的洞放在那不管以后用作什么,是不是能很好解决呢?这就是OOA OOD的价值

当然了,如果要把地下室改成飞机跑道那就还是无解,这属于畸形业务、需求,并且已经跨领域了,经验再丰富的分析师也没有办法解决,只能推倒重来

顺带一提,OOA ,OOD,OOP,他们正是DDD的基础支撑,不严谨的说,DDD是他们落地方法论的一种,但OO最大的问题在于一股脑去体现 "结构"的表达,而DDD丰富了他们,其中最主要的是丰富了 "行为"的表达

  复杂性

  人在处理复杂事物时有自身的能力局限,如航空交通控制系统,必须同时处理不同飞机的状态、面对相当大的、交错的、非确定性的等等状态空间,一个人绝对没有办法跟踪所有细节

  一些心里学家实验表明,人能同时理解的额最大信息数量是7个左右,大脑需要大约5秒才能接受一组新的信息,并不仅仅只有程序员是金鱼的记忆,所有人都是如此

  工业级软件所涉及的问题域本身太大,单个开发者要理解它设计的所有方面太困难,甚至可以说这些系统的复杂性超出了人类智能范围,虽然我们可以掌握这种复杂性,但无法消除它

  现状

  简单的系统不谈,基于复杂系统的层面上,开发初期

  需求方很难用开发者容易理解的方式对需求给出准确的表述,常见的描述方法是用一大段文字偶尔配有草图,这样的文档难以理解,因为双方都缺少另一个领域的经验,双方完全站在了不同角度看待问题

  还一个问题是,程序员缺少了系统的、合理的分析与设计方法,只将看到的东西如实反映在程序中,也就是并没有对未来进行预判,或者进行了预判但没有使用正确的设计方式

  结果就是程序员开发完成,用户或需求方在经过使用之后,会对需求有更好的理解和表述,同时这个过程也帮助开发者了解了问题域,使他们能问出更好的问题从而发掘出隐藏着的真实需求,对老系统进行不堪入目的改造

  这种过程是在一直循环的,企业成本明显提升,老板抱怨程序员任务完成周期太长。程序员自己也痛苦,抱怨需求变态

  一般来来说,修正错误是维护,应对改变是演化,而当我们使用一些极端手段来保持系统能继续工作时,这是保护,目前看来大部分开发者在面对修正或改变时,不得不同时进行保护

  分而治之

  分解系统的空间状态,可以直接解决软件的复杂性,更好的理解与设计系统

  目前的分解方式有两种,一种是算法分解,一种是面向对象分解,不能说哪种好哪种不好,在不同的阶段不同的场景都有各自的重要性

  对于一个系统,最开始能接收到的信息只有一份基本需求,里面有所需的业务描述,下手的地方就是阅读,找出各种名词、动词等词语

  算法分解

  算法分解强调事件的顺序,围绕业务的动词建立起来,它是一种自顶向下的结构化设计,这导致了程序具有树的形态,面向了过程

  当系统代码数量太多,比如超过10万行时,这种方式似乎就不行了,因为各处耦合而不利于伸缩,尤其是对于复杂系统

  但用于某一具体场景时,却可以很直观的看出各流程节点逻辑、关系

  面向对象分解

  面向对象分解强调了代理,根据问题领域中的关键抽象概念对系统进行分解,每个对象都是真实世界某个对象的模型,它们要么发出动作要么就是这些操作执行的对象

  通过复用共同的机制得到一些较小的系统,提供了更加低成本的表达性,作为真实世界实体的抽象,语义上也更加贴近业务,自身又代表了一块密集又内聚的信息,将巨大的状态空间进行关注点分离,直接关注了软件的内在复杂性

  并且,对象模型在规模上可以扩展,一组抽象可以构建在另一组抽象之上,可以用更加宏观的视角来观察分析

  它围绕各种类型的词语建立起来,具体说来,比如名词代表某一对象,动词代表对象的行为,动词词组代表关联并可能引申出场景,对象又需要分析它的结构,对象与对象之间可能又共享某一场景,这又需要合理的组织,等等等等

  

  结构

  植物包含三种主要结构,根、茎、叶,他们各自又拥有不同的特有的结构。例如根包含支根、根毛、根冠,叶有表皮、叶肉、纬管束

  这些结构又由一些细胞构成,每个细胞内还可以发现另一层的复杂度,如细胞核等

  他们的各个部分组成了一种层次结构,层次结构中的每一层又都有着各自的复杂性

  植物细胞由刚性的细胞壁包围,但动物细胞却不是如此,尽管存在着差异,但不管怎么说这些结构都是细胞,这是跨领域共性的一个简单例子

  组织

  发现共同的抽象和机制可以促进对复杂系统的理解,一个有经验的飞行员,可以很快学习驾驶一架从未驾驶过的飞机,因为飞行员在学习之初就已经了解了他们的共同抽象:舵、节流阀等,只需要花点时间去学习这架飞机的特有特性:比如哪个按钮发射导弹之类

  其实这说明层次结构的使用方式是很宽泛的,复杂系统往往有许多不同的层次结构

  分析PC主机时,我们可以将它分解为主板、显卡、CPU等,这是一种结构上的层次结构,或者说组成部分的层次结构

  而换一种方式分析,GTX980与HD4600都是一种具体的显卡,显卡代表了他们的共同抽象,这代表了"是一种( is a )"的层次结构,他们又有一些独有特征,比如GTX980可以运行很多大型游戏而HD4600却不能,这能帮助我们进一步掌握它们内在的复杂性

  我们可以把这些结构分别称为"类结构" 和 "对象结构"(并非具指代码中的类和对象)

  ( 面向对象分解的建模 )  

OOA/D  01

OOA/D  01

  (附加了四色原型模式的对象建模)

  OOA/D  01