我有一个名为List_Field的类，顾名思义，它构建列表输入字段。这些列表输入字段允许用户为每个列表选择一个项目。
我希望能够构建列表输入字段，允许用户为每个列表选择多个项目，因此我遇到以下困境：
我应该通过在现有multiple_choice_allowed属性中实现List_Field属性来实现这一点，还是应该实现Multiple_Choice_List_Field类的List_Field子类？
面对像这样的困境，我应该遵循什么工程原则？
答案 0 :(得分：19)
看看SOLID principles。他们会帮助你完成你的设计。特别是，单一责任原则会告诉你不要将这两个问题混合在一个类中，Liskov替换原则会告诉你不要创建违反超类合同的子类，就像你提出的那样。
那么你的案例中的解决方案是什么？您可以创建一个与选择类型无关的抽象基类，然后创建2个子类，一个用于单个选择，另一个用于多个选择。
答案 1 :(得分：3)
取决于对象演变的存在/缺乏 - 如果你想要特殊情况，子分类或注入（DI）“选择”行为（策略）是好的。
但是如果你还想允许Field_List动态地改变它的行为，那么属性或变异方法是唯一的方法。
示例：具有不同“计划”的注册屏幕 - 基本，您只能选择一件事和高级版，您可以根据需要选择。计划的更改将在下拉列表和多个复选框之间切换，同时仍然具有相同的对象，包括其内容。
我会投票选择property / mutate方法。
答案 2 :(得分：2)
就个人而言，我会采用Multiple_Choice_List_Field方式。我不认为有一个严格的标准或工程原则会让你以一种方式而不是另一种方式来做。
更重要的是选择一种方法来做到这一点，并在遇到这种困境时遵循它。你应该保持一致，但你走哪条路是你自己的选择。
我会选择子类，因为这样你就不必为List_Field类增加额外的检查和要求。当然还有其他一些注意事项，比如如果你需要在运行时切换多项选择和单项选择，那么最好选择boolean属性（尽管子类也可以工作，但对我来说并不自然）。
另一件事是List_Field您可能需要多个属性来处理多个选项，具体取决于您当前的实现。例如，一个新属性，用于返回所选项的数组。
只需按照最舒适的方式进行构建和维护（并最终扩展）。
答案 3 :(得分：1)
我应该通过实施来做到这一点 multiple_choice_allowed属性 进入现有的List_Field属性
如果你能做到这一点，我认为这是最好的解决方案，因为这样可以避免类扩散。 如果这样做会使List_Field类过于复杂，那么创建派生类可能会对代码的可维护性产生一些好处。
答案 4 :(得分：1)
就个人而言，我不会说：而是使用一个带有multiple_choice_allowed的构造函数，然后使用一个属性将ListFields暴露为一个集合（当只允许一个元素时只有一个元素，当允许多个元素时，所有元素都是如此）。将其设为只读（这意味着您应该在返回列表时复制它）。