单独的Options类、重载构造函数或具有默认值的公共属性
本文关键字：默认值 属性 构造函数 Options 重载 单独 | 更新日期: 2023-09-27 18:24:13
我一直在做一个项目，我有一个Worker类，它以多线程的方式生成大量数据。数据的类型、大小和位置是可变的，这取决于最终用户可以设置的一大组参数。从本质上讲，这是一个大型测试工具，我正在使用它来研究某些事情是如何基于数据的变化来执行的。现在，Worker类至少有12个不同的参数。我正在考虑切换到一个单独的WorkerOptions类，该类包含所有这些值，然后让UI创建WorkerOptions对象，然后将其传递给Worker。但是，我也可以公开Worker类上的公共属性，以便在Worker创建时也可以适当地设置选项。
最好的方法是什么，为什么？我相信这会产生一些不同的意见，但我愿意听取关于为什么不同的人会用不同的方式来做这件事的辩论。需要考虑的一些事情是，当前一旦创建并运行Worker，它的配置就不会改变，除非它停止。这可能会改变，但我认为不会。
编辑我通常不是C#开发人员，我知道足够的知识来编写能够正常工作并遵循常见设计模式的应用程序，但我的专业知识是SQL Server，所以我可能会问一些后续问题来澄清你的意思。
我的指导原则是，使用实例所需的参数应该在构造函数中传递，所有"可选"参数都应该是属性。
属性当然会在构造函数中初始化为默认值。
如果参数的数量不多，我会使用默认值参数，但12是相当多的。
我忘了提选项的单独课程。大多数情况下，我不会做这样的事情，除非选项中有一些"业务逻辑"（比如检查某些选项组合是否不可能）。如果它只是用于存储，那么最终会有很多对该选项类（实例）的额外引用。
我会将这两种方法结合起来。
使WorkerOptions类使用一个构造函数，该构造函数需要所有必需的参数，并允许通过重载、可选参数或属性设置可选参数，然后将其作为参数传入。
拥有WorkerOptions类可以为您提供一个很好的DTO，以防重构导致您在UI和worker类本身之间创建一个额外的层。在其构造函数中使用必需的参数可以进行编译时检查，以防止运行时错误。
就我个人而言，根据您所说，我更喜欢WorkerOptions方法。原因如下：
- 它更干净，12个构造函数参数不是不可能的，但可能有点过分
- 您可以将多态性和所有其他OO优点应用于WorkerOptions。您可能希望在某个阶段定义IWorkerOptions，或者使用Builder构建WorkerOption的不同子类
我还将使所有WorkerOption实例都是不可变的，或者至少提出一个"锁定"或"冻结"机制，以防止在Worker开始执行后发生更改。