目前我正在考虑以下结构：

StandardName (namespace) --> Year(namespace) --> actual implementation of particular standards Class

这里的问题是，标准从一年到另一年的变化都需要将所有类复制到新的命名空间，尽管其中一些可能根本没有改变。有没有有效的方法？或者我错过了什么？

Answer 1

根据您的标准，OO可以很好地处理这个问题。最基本的支持是您的类需要实现的接口。这意味着除非您在实现中开始使用委托，否则不会重复使用。

或者，如果标准只是增长（即旧功能永远不会改变），那么你可以通过继承来完全支持它。

在现实世界中，您将混合使用这三种方法。常用代码将进入基类和委托，因此您只需复制几行代码即可获得大部分功能。然后从头开始或通过覆盖现有实现来实现其余部分。

Answer 2

我认为正确的封装是关键。

标准的某些部分必须在版本之间保持不变，以便实现的某些部分应该或多或少地稳定。

如果您知道哪个部分最有可能保持不变，那么您可以特别注意这些部分的封装，以便最大化可重用性。另一方面，对于更有可能被提炼的部分，你应该尽可能多地抽象...特别是如果规范必须扩展（添加一些功能但保持旧的完整）。

不要害怕在版本之间重构 ......你可能第一次弄错了。而不是重新开始或复制粘贴旧部分到新实现，重构您的设计，改进它，改变它。随着版本的推移，您将能够更好地了解规范如何发展。

Answer 3

要求问题：

如果您的标准是向后兼容的，那么在实现新版本时，您可以继承旧版本的类。

如果不是，但版本不必共存，只需根据需要更改旧源代码，并每年发布一个新版本。

如果它不向后兼容，并且几个版本必须共存，则可能需要使用命名空间分隔。当然，如果你的标准使用单身人士，那么这可能会带来问题，每个版本都有自己的版本，这可能会打败期望。

底线：如果可能的话，我会避免命名空间分离，但你可能需要它。

Answer 4

我认为同样的“标准”每年都相当稳定。如果是这样，您应该能够保持此标准的接口稳定。所以我建议你使用一个factory方法，它可以用一些参数来指定客户想要的标准年份/版本。这允许您隐藏实际的实现，因此客户端根本不必担心不同的命名空间。此外，您可以避免不必要的名称冲突。

如果标准每年变化很大以保持稳定的界面，您仍然可以通过应用声音OO技术（如继承和组合）来重用现有代码。

Answer 5

你的新课程可能需要新名称，因为他们做了不同的事情。

Qt4允许用户在移植应用程序时启用QtSupport选项以访问Qt3代码。默认情况下，删除对旧代码的支持并使用户明确启用它。这样，用户可以使用较新版本轻松使用旧版应用程序，但新项目不会使用旧代码。

Answer 6

我不明白你的标准究竟是什么，但有时你只需要改变一些系数，费率等等（例如，贷款利息或任何当前的门槛。）

如果是这种情况，那么我更愿意将每个值与DateTime Applied列一起存储在数据库中，因此我必须执行以下查询以确定当前值：

SELECT TOP 1 Value WHERE Key = %A AND Applied <= GETDATE() ORDER BY Applied DESC

此解决方案的优点是，如果您知道在某段时间内（例如几个月）应用某些更改，那么您只需添加适当的数据库记录，并在时机成熟时应用更改。缺点是除了值之外很难存储任何其他内容，您需要设计适当的缓存，以便每次访问都不会访问您的数据库，但会在应用新值时更新它。