类版本控制以支持向后兼容性

Question

在我工作的项目中,我们处理医疗账单.

每次状态对官方表单(我们的数据类表示)进行更改时,为了保持与以前表单的向后兼容性,我们添加新属性但保留旧属性,并具有使用的文档版本属性确定完成哪些验证以及显示它的UI操作.

这导致了项目生命周期内的繁琐课程(近5年的国家法定变更),而且根本不支持旧文档格式不是一种选择.

我想尝试为每个文档版本创建一个新类,但即使这样,我们也会有几个非常相似(虽然稍有改动)代码的副本.而ProgressNoteV16,ProgressNoteV17等类名看起来很可怕.

不能使用继承,因为这仍然会导致相同的问题(具有不再需要的属性的类).接口会使接口变得臃肿,这无法解决问题.

用于解决此问题的解决方案和最佳实践是什么？

Answer 1

对于任何与公众合作的机构来说,这是一个相当经典的问题,特别是如果它是政府或政府监督的机构.解决方案非常重要,它可能需要一些重要的工作来创建,以及之后的维护.

这对我来说在为客户处理类似问题时起了作用,但它可能对你不起作用,你需要草拟你想要完成的事情以及是否有意义这样做.

有几种模式需要熟悉(如果你还没有):

1. 工厂已经提到过
2. 希望能让你摆脱一些丑陋的继承问题的作文
3. 用于从表单中分离出表单的逻辑的模板

有两本书非常适合解释这些(以及其他一些有用的):

1. 首先设计模式(不记得我的头顶)
2. 企业应用程序架构模式(Fowler)

现在我过去使用的过程:

1. 首先获取所有当前版本的表单,将它们分成不同的类并查找常见的重叠.您可以在草稿模式下执行此操作,也可以作为当前计划为每个版本创建不同的类
2. 从此类结构派生出一些"基础"对象,您可以将这些对象用作表单的每个重要版本集的继承根.您可能有其中的几个,但它们应该比您拥有的总表单对象少.
3. 现在,在每个基础对象中,将常用功能(即名称和地址结构等)组合在一起,并将其抽象到自己的类层次结构中,通过构造函数注入将此hieararchy注入到基类中.
4. 现在将组合模式应用于基类层次结构,并尽可能多地获取通用类结构.理想情况下,此时您的表单只是每个表单中已更改的最小功能,并且具有一个构造函数,该构造函数采用所有常见(可能稍微变化)的功能.
5. 现在应用模板模式来抽象出类中的所有常用"功能",例如通用验证和持久性逻辑,再次使用构造函数注入将此功能恢复到基类中.
6. 从基类中提取接口适配器定义,并使用这些定义作为应用程序使用表单的基础
7. 构建你的工厂类来处理设置它的所有蹩脚工作.

希望能给你一些关于做什么的想法.