使用 C# 在此应用程序中应用开闭原则的最合适方法是啥？

Posted 2023-03-15

【中文标题】使用 C# 在此应用程序中应用开闭原则的最合适方法是啥？

【英文标题】：What's the most appropriate way to apply the Open-Closed Principle in this app using C#?使用 C# 在此应用程序中应用开闭原则的最合适方法是什么？

【发布时间】：2010-07-30 11:35:30

【问题描述】：

场景

每晚我们都会对大约一百万份客户合同进行一系列计算。每份合同都与一组大约十种产品相关，其中每一种产品都可能对要​​执行的计算集采用变化（尽管总体流程大致相同）。给定产品的所有合同将在任何给定的夜晚使用相同的计算集；分布不均，从最小的几千到最大的几十万不等。

随着时间的推移，我们将添加新的类似（但不太可能完全相同）产品，并且现有产品可能会通过对所采用的算法引入变化来进行调整。 （顺便说一下，我希望算法能够在不修改代码的情况下进行参数化）。

我们用来支持这一点的核心“引擎”应该适用于产品开发和生产。后者由我们的运营人员管理，他们对自己接受的内容以及一般如何管理变更非常谨慎。

在考虑架构时，我被Open-Closed Principle 深深吸引：

软件实体应该开放给 扩展，但关闭 修改。

由于我们计划在 C# 中实现，我正在考虑规定函数在内核外部定义，以文本形式加载并在运行开始时编译，以用于在当前版本的控制下的产品产品定义。这些组件中的每一个都将编译为一个类，该类实现在应用程序的已编译元素中定义的接口（或等效接口）。我乐观地认为，从运营的角度来看，这将被视为一个加分项，因为回归测试的范围大大减少了。

问题

这有意义吗？任何人都可以就潜在的陷阱提供任何明智的建议吗？

我是否重新发明了依赖注入，我是否最好通过每次提供一个新的 DLL 来提供常规更改？如果是这样，这会使我们的日常产品开发过程变得更糟吗？

或者我应该采用更敏捷的方法，端到端构建一个产品，然后依次添加其他产品，看看我重构时会出现什么架构？

如果你还在我身边，谢谢你的耐心...

【参考方案1】：

使用依赖注入来创建一个类，该类的进程方法采用 IProcess 参数。为实现此接口的每种产品类型创建一个不同的类，每个类都应该在它自己的 DLL 中。创建一个配置文件以将产品类型映射到进程 dll 和类。然后，您可以使用反射读取配置文件并加载相关 dll，然后将它们传递给 DI 类的 process 函数。这样您就可以通过简单地创建一个新的 DLL 并更新配置文件来添加一个新进程。更改现有进程只是更新相关类和重新部署 dll 的问题。

【讨论】：

+1。 @Mike - 是的，你正在重新发明 DI。使用接口将允许您实现 Open/Closed。您仍然可以对第一个端到端产品的接口采取敏捷方法，但您会希望很快地完成它们；请参阅：稳定依赖原则和稳定抽象原则。