最近在对项目中的某一模块进行重构和功能的拓展。一直没想到好方法。

简单理解为： R项目 调用了 E项目的打印接口，但是E项目需要对R传来对数据传输对象DTO进行二次处理，甚至夹杂很多R项目的业务逻辑（去调用R项目的接口），经过多个迭代以后，R项目和E项目的接口对接人已经成为了相亲相爱一家人👨‍👩‍👧‍👧。

Team leader 一语点醒：“依赖倒置”

突然感觉到自己以前对于OOP的各种概念还处于浮于表面的理解。实战中还用不出来。

举个栗子🌰

     传统：

     开始的电脑，各组件（内存、显卡等）根据某个厂家的产品直接焊接集成到一起。

     DIP:

     各组件都定义标准接口，主板上预留标准接口，各厂家按标准接口来生产。

     这样就很容易更换不同厂家的产品。

     传统系统：高层模块依赖低层模块。

     DIP第一层境界：低层模块依赖高层模块。

     DIP第二层境界：无论高层模块或低层模块实现的细节，都依赖于独立出来的抽象层。

 

依赖倒置原则应用广泛，在面向对象程序框架设计中（是核心原则）、架构系统中、在社会活动构建组织等方面，都发挥重要作用。

     DIP在面向对象程序设计中，面向接口编程是基础，而核心是"依赖倒置"。

     一般来说，系统中存在违反DIP的地方，很可能就是我们需要优化的地方。

好的回到项目开始思考：

    1. E项目不应该关注R到业务逻辑

    2. R项目只应该调用最通用的E项目接口，并且进行单项数据流，不应该出现反复横跳

基于现有的问题，首先为什么E会关注R的业务？R的DTO处理不够干净，九转大肠，接口对接人还需要干一些脏活累活。

从代码层面来说，E应该只定义接口的规范，具体的实现让R来做，比如打印类的定义可以直接继承自R项目的DTO，这样不会因为业务的频繁变动而导致对接人的工作量增加。

其次，抽离最通用的业务，即打印的逻辑，打印函数不关心你的DTO如何定义，只负责获取到并且DFS解析出，根据某具有唯一性的key来进行模板的数据替换。 同样的，替换模板的生成也不应该关注R的业务，根据R定义的DTO/Entity 来动态生成的对应的XML。

动态生成XML已经实现了，基本上思路就是根据Entity及其guid，生成对应的节点，设置唯一属性GUID方便后期替换数据。

XML Documents and Data | Microsoft Learn

那么具体实现到何种境界，还需要一段时间的思考🤔

此blog 待补充。。。