实现属性或实现子类

看看 SOLID 原则。他们会在你的设计中帮助你。特别是，单一责任原则会告诉你不要在一个类中混合这两个关注点，而 Liskov 替换原则会告诉你不要创建破坏超类契约的子类，就像你也提议的那样。

那么，在您的情况下，解决方案是什么？您可以创建一个与选择类型无关的抽象基类，然后创建 2 个子类，一个用于单选，另一个用于多选。

取决于对象进化的存在/缺乏 - 如果你想要特殊情况，子类化或注入（DI）"选择"行为（策略）是好的。

但是，如果您还想允许Field_List动态更改其行为，那么属性或突变方法是唯一的方法。

示例：具有不同"计划"的注册屏幕 - 基本，您只能选择一件事和高级，您可以选择任意数量。计划更改将在下拉和多个复选框之间切换，同时仍然具有相同的对象，包括其内容。

我会投票给属性/突变方法。

就我个人而言，我会选择Multiple_Choice_List_Field的方式。我不认为有一个严格的标准或工程原则会让你以一种方式而不是另一种方式去做。这里更重要的是选择一种方法来做到这一点，并在遇到这样的困境时遵循它。你应该保持一致，但你走哪条路是你自己的选择。

我会选择子类，因为这样你就不必通过额外的检查和要求来膨胀你的List_Field类。当然还有其他考虑因素，例如如果您需要在运行时切换多项选择和单选，最好使用布尔属性（尽管子类也可以工作，但对我来说并不自然）。

另一件事是List_Field您可能需要多个属性来处理多个选择，具体取决于您当前的实现。例如，用于返回选定项的数组的新属性。

只需以您最舒适的方式构建和维护（并最终扩展）即可。

我应该通过实施来做到这一点吗 multiple_choice_allowed属性 到现有List_Field属性中

如果你能做到这一点，我认为这是最好的解决方案，因为这样你就可以避免阶级扩散。如果这样做会使List_Field类过于复杂，也许创建一个派生类可以对代码的可维护性有一些好处。

就个人而言，我不会说两者都不是：而是使用一个接受multiple_choice_allowed的构造函数，然后有一个属性将 ListFields 公开为集合（当只允许一个元素时只有一个元素，当允许多个元素时，所有元素）。 将其设为只读（这意味着您应该在返回列表时复制它）。