代码之家 › 专栏 › 技术社区 › µBio

变更容限建议

backwards-compatibility winforms c#

µBio · 技术社区 · 15 年前

背景:
我将致力于开发依赖于快速变化的API和快速变化的数据模型的工具,在这些模型上我将拥有零控制权。

数据模型和API更改是常见的,这里的问题是我的代码必须继续与当前和所有以前的版本(即100%backwords兼容性)一起工作,因为所有版本都将继续在内部使用。

当它遇到丢失/未知功能等时,它也必须优雅地降级。

这些工具将使用WinForms用C编写,用于测试自定义硬件。

<Edit>

我的目标是只需要创建类来添加特性,当数据模型发生更改时,创建一组新的数据模型类,这些类将由工厂基于API版本创建。

我面临的挑战是,未来的特性可能取决于特定的数据模型,这些模型可以混合和匹配(直到达到最终的组合)。你将如何处理这个优雅?

<Edit2>

当然,一旦产品发货,我就想重用这个工具,只需为新产品添加代码。在我开始之前,每一个产品周期都意味着重写(从头开始)所有工具,这是我将来要防止的事情:)

</Edit>

问题:
您建议或已经成功使用哪些设计技术和模式来保持与API/数据模型的多个版本的兼容性?

我应该注意哪些陷阱?

7 回复 | 直到 15 年前

Mark Seemann 15 年前

几乎所有的固体模式在这里适用,但特别是 Single Responsibility Principle (SRP)和 Open/Closed Principle (OCP)。

OCP特别声明类型应该是 打开进行扩展,但关闭进行修改 -这听起来很适合您的情况,因为这是一种确保向后兼容性的方法。

SRP在这里也非常有用,因为它意味着如果一个类只做一件事,而这件事变得过时了,它不会拖累很多其他问题。它可以自己去死。

在更实际的层面上,我建议您遵循两个原则:

针对接口(甚至 better for backwards compatibility: abstract base clasess )
使所有(或大多数)公共成员成为虚拟成员

TDD(或者仅仅是一个综合的单元测试套件)将帮助您防止破坏性的更改。

Bevan 15 年前

埃里克·埃文斯在书中讨论的“反腐败层”可能是一个有用的想法。 Domain Driven Design -这个模式的主要动机是将你的系统与另一个系统的变化(和特性)隔离开来。

Square Rig Master 15 年前

您提到代码用于测试自定义硬件。您的代码(即测试例程)也会改变吗?您的代码将在今天测试一个圆,明天测试一个三角形,还是每天都在不断发展的相同的基本圆?

如果有一个常数点在周围移动,那么我将从那里开始,为每个版本的API和数据模型编写包装器,这些包装器将根据其他答案中建议的技术链接到中心。

但是,如果没有不变点,一切都在移动,那么我就放弃这个项目!这是不可能的!

Doc Brown 15 年前

您的API/数据模型是否为您提供元数据?如果是这样,那么最好使用它使代码尽可能独立于API更改。例如,如果您有机会通过使用数据模型模式生成数据模型访问例程,那么应该这样做。当然,这只对某些类型的操作有意义。

Anon. 15 年前

编写自己的包装器,以便在代码和不受控制的内容之间进行接口。然后,您可以根据包装器公开的API编写代码,只需担心包装器本身的互操作性。

Steve 15 年前

您最好的选择是让您公开的API需要一个版本号来加入请求。这样就可以选择要创建的正确对象。最坏的情况是,每一个变化都会中断,最终你会得到几十个类。最好的情况是,您的设计可以处理它,并且您只能偶尔使用单独的类。继承权可能会成为你在这件事上的朋友。最重要的是,如果需要与快速变化的API保持100%的向后兼容性,那么基本上就是拧了。您要么最终得到一个巨大的不可维护类,要么得到几个对版本控制做出正确响应的类。

Larry Watanabe 15 年前

1)大量单元测试。

每当您编写一段代码时,都要为代码发布许多单元测试,将来的版本必须通过这些测试才能签入。

确保测试是基于功能需求的,即不是函数的编写方式,而是为了不破坏其他代码而必须做的事情。

这将帮助人们签入破坏其他代码的更改。

2)要求所有API和数据模型有良好的正式规范。这确保了它们的设计更为仔细,并且在没有思想或理由的情况下,不会随意地进行更改。