单独的Options类，重载的构造函数或具有默认值的公共属性？

Question

我一直致力于一个项目，我有一个Worker类，以多线程方式生成大量数据。数据的类型，大小和位置可根据最终用户可设置的大量参数进行变化。从本质上讲，这是一个很大的测试工具，我用它来研究某些事情如何根据数据的变化执行。现在我为Worker类至少有12个不同的参数。我正在考虑切换到包含所有这些值的单独的WorkerOptions类，然后让UI创建WorkerOptions对象，然后将其传递给Worker。但是，我还可以在Worker类上公开公共属性，以允许在创建Worker时适当地设置选项。

最好的方法是什么，为什么？我相信这会产生一些不同的意见，但我愿意听取有关为什么不同的人可能以不同的方式做到这一点的辩论。需要考虑的一些事情是，一旦创建并运行了一个Worker，它的配置不会发生变化，除非它停止。这可能会有所改变，但我认为不会。

修改 我通常不是C＃开发人员，我知道能够编写功能和遵循常见设计模式的应用程序，但我的专业知识是在SQL Server中，所以我可能会提出后续问题来澄清你的意思。

Answer 1

我的指导原则是，使用实例所需的参数应该在构造函数中传递，所有“可选”参数都应该是属性。

属性将在构造函数中初始化为其默认值。

如果参数的数量不高，我使用默认值参数，但12是相当多的。

我忘了提及选项的单独课程。除非在选项中有一些“业务逻辑”（比如检查某些选项组合是否不可能），否则我不会做这样的事情。如果它只是用于存储，那么最终会有一些对该选项类（实例）的额外引用。

Answer 2

我将这两种方法结合起来。

使您的WorkerOptions类使用需要所有必需参数的构造函数，并允许通过重载，可选参数或属性设置可选参数，然后将其作为参数传递。

拥有WorkerOptions类为您提供了一个很好的DTO来传递，以防重构导致您在UI和工作者类本身之间创建一个额外的层。在构造函数中使用必需的参数可以进行编译时检查以防止运行时错误。

Answer 3

就个人而言，从你所说的，我更喜欢WorkerOptions方法。原因如下：

• 它更干净，12个构造函数参数不是不可能的，但它可能有点过分。
• 您可以将多态性和所有其他OO优点应用于您的WorkerOptions。您可能希望在某个阶段定义IWorkerOptions，或使用Builder构建WorkerOption的不同子类。

我还会让所有的WorkerOption实例都是不可变的，或者至少提出一个'lock'或'freeze'机制来阻止一旦Worker开始执行后的更改。