依赖示意图如何称之为模型
Posted Ariel_欢
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了依赖示意图如何称之为模型相关的知识,希望对你有一定的参考价值。
背景:写一篇小论文,论述下图如何称之为模型
一、从概念入手,什么是模型?
模型:通过主观意识借助实体或者虚拟表现,构成客观阐述形态结构的一种表达目的的物件(物件并不等于物体,不局限于实体与虚拟、不限于平面与立体)。【来自百度百科】
模型(model):模型是指对于某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式。【来自MBA智库百科】
个人理解:模型是我们对于某个实际问题或客观事物、规律,通过主观意识借助实体或虚拟表现进行抽象后,构成客观阐述形态结构的一种形式化表达方式。
二、需求剖析,代码优化过程:
从米老师让何老师开门这个实际需求出发,我们从第一版的面向过程代码(直接写在Client类中),经过一次次的沟通和老师的指导,我们先后优化了很多版,主要是从面向对象的角度,从注重具体的实现步骤,到注重谁来干事,优化出来两种建模方式:米老师依赖于何老师和何老师依赖于米老师:
建模方式一:米老师依赖于何老师
建模方式二:何老师依赖于米老师
这两种都是存在直接的依赖关系,代码逻辑上的体现是“谁在谁肚子里”。
我们经过研究设计模式书P362页的猫和老鼠示例,猫叫老鼠跑,但是猫和老鼠并没有直接的依赖关系,是通过委托与事件实现的猫和老鼠没有直接的依赖关系。从而引发我们的思考,如何让米老师和何老师在代码编写和编译时不产生直接的依赖关系,但是在运行时是可以具体产生依赖关系呢?——引出我们的抽象模型,如下图所示:
三、抽象模型的理解与思考:
这个抽象的图示模型可以看出Mi类的“肚子里还是有所依赖的”,但是具体依赖的是谁并不知道,而是在运行时具体知道依赖的是谁。这样让我们的Mi和He在编写代码时以及编译时都没有产生直接的依赖关系(或者说强依赖关系),而是通过反射实现在运行时产生依赖关系,这个依赖关系是弱依赖,是可替换、可拓展的,更符合面向对象的开闭原则,同时也符合迪米特法则和单一职责,米老师只需要发消息,并不需要知道谁来开门。
有了这样的模型架构,一层一层的架子,看着很虚,但是符合工程化:
快速(多人同时开发,保证不冲突)、规模大、低代码,低成本、代码解耦合、高复用、高拓展、高维护。
产品上线以后:
扩充:随着使用的人数逐渐增加,用户需求的变化,可拓展
维护:一个功能的多样化,可以通过配置进行维护
以上是关于依赖示意图如何称之为模型的主要内容,如果未能解决你的问题,请参考以下文章