依赖示意图如何称之为模型

背景：写一篇小论文，论述下图如何称之为模型

一、从概念入手，什么是模型？

模型：通过主观意识借助实体或者虚拟表现，构成客观阐述形态结构的一种表达目的的物件（物件并不等于物体，不局限于实体与虚拟、不限于平面与立体）。【来自百度百科】
模型(model)：模型是指对于某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式。【来自MBA智库百科】

个人理解：模型是我们对于某个实际问题或客观事物、规律，通过主观意识借助实体或虚拟表现进行抽象后，构成客观阐述形态结构的一种形式化表达方式。

二、需求剖析，代码优化过程:

从米老师让何老师开门这个实际需求出发，我们从第一版的面向过程代码（直接写在Client类中），经过一次次的沟通和老师的指导，我们先后优化了很多版，主要是从面向对象的角度，从注重具体的实现步骤，到注重谁来干事，优化出来两种建模方式：米老师依赖于何老师和何老师依赖于米老师：
建模方式一：米老师依赖于何老师

建模方式二：何老师依赖于米老师

这两种都是存在直接的依赖关系，代码逻辑上的体现是“谁在谁肚子里”。

我们经过研究设计模式书P362页的猫和老鼠示例，猫叫老鼠跑，但是猫和老鼠并没有直接的依赖关系，是通过委托与事件实现的猫和老鼠没有直接的依赖关系。从而引发我们的思考，如何让米老师和何老师在代码编写和编译时不产生直接的依赖关系，但是在运行时是可以具体产生依赖关系呢？——引出我们的抽象模型，如下图所示：

三、抽象模型的理解与思考：

这个抽象的图示模型可以看出Mi类的“肚子里还是有所依赖的”，但是具体依赖的是谁并不知道，而是在运行时具体知道依赖的是谁。这样让我们的Mi和He在编写代码时以及编译时都没有产生直接的依赖关系（或者说强依赖关系），而是通过反射实现在运行时产生依赖关系，这个依赖关系是弱依赖，是可替换、可拓展的，更符合面向对象的开闭原则，同时也符合迪米特法则和单一职责，米老师只需要发消息，并不需要知道谁来开门。

有了这样的模型架构，一层一层的架子，看着很虚，但是符合工程化：

快速（多人同时开发，保证不冲突）、规模大、低代码，低成本、代码解耦合、高复用、高拓展、高维护。

产品上线以后：
扩充：随着使用的人数逐渐增加，用户需求的变化，可拓展

维护：一个功能的多样化，可以通过配置进行维护