Question

好的，所以我在这里设计课程，我有两个选择。我可以写多个方法，也可以用一个方法来表示Enum。

我正试图找出最佳方法。

让我们举一个例子：

public class myClass
{ ...
    public void DoStuff1()
    { ... Do Stuff ... }

    public void DoStuff2()
    { ... Do Stuff ... }

    public void DoStuff3()
    { ... Do Stuff ... }
}

好的，一切都有道理，现在另一种方式是：

public class myClass
{ ...

    public Enum Option
    {
        Option1,
        Option2,
        Option3
    }

    public void DoStuff(Option option)
    { ... Do Stuff ... }
}

就DRY而言，它们并不是那么糟糕，因为无论如何代码几乎都会调用内部方法，所以它只是用户可以看到的内容供他们选择。

那么您更喜欢为什么，并且有没有针对此的指导原则？

Answer 1

只是我或我实际上在这里闻到了Command design pattern吗？

Answer 2

多种方法适合我。

从开发人员方面来说，我不需要在DoStuff（）中维护方法/命令代码和开关案例的枚举
从客户端来看，我认为这并不重要。

更新：如果这个类没有做实际的工作，并且更多的转发器/委托工作到正确的对象，那么我会看看正如这里正确指出的那样实现Command Design Pattern。 / p>

Answer 3

这取决于您的选择有多相似。从某种意义上说，如果您的算法/方法将根据选项发生巨大变化，那么最好使用多种方法。如果它相对类似，那么请使用枚举。

Answer 4

当方法中的大多数代码以某种方式相关时，我只会使用第二个选项（so参数），而枚举选项仅指定方法行为的一个小变化。当该选项会大幅改变函数的效果时，最好使用单独的方法。它使代码更具可读性，无论如何你可能会在函数中使用某种case语句，有效地使事情变得比它们需要的更复杂。

我认为使用选项参数时的一个很好的例子是“GetData”函数，其中option参数仅指定数据的来源（即来自当前数据库或来自档案），但其余的机制是相同的对于这两种情况。

Answer 5

您需要考虑每个执行路径的目的。选项1,2和3的行为非常相似，只是以较小的方式改变？或者所有三个选项都不同，以更重要的方式变化？即使每个选项都相似，那么表示这些选项的操作的更清晰的方式是什么？具有值Option1，Option2和Option3的枚举非常有用。

你也应该问自己......我会停下三个选择吗？将来需要三个以上的可能性有多大？你还需要更多吗？也许需要一种更加面向对象的方法。

有许多工具可以帮助您确定解决问题的方法。 Design patterns，anti-patterns，可能books on refactoring可以帮助提供一些解决问题的资料。

Answer 6

在第二种情况下，如果DoStuff看起来像这样

public void DoStuff(Option option)
{ 
  switch (option)
  {
     case Option1: /* Stuff 1 */ break;
     case Option2: /* Stuff 2 */ break;
     case Option3: /* Stuff 3 */ break;
  }
}

然后它可能不是一个好主意。但最重要的方面是：哪一个使用此类为其他类创建更好的API？很难说这是一个抽象的例子。如果第二个选项更有意义，你仍然可以实现第一个方法（使DoStuff1..DoStuff3成为私有或受保护）并实现DoStuff，如

public void DoStuff(Option option)
{ 
  switch (option)
  {
     case Option1: DoStuff1(); break;
     case Option2: DoStuff2(); break;
     case Option3: DoStuff3(); break;
  }
}

Answer 7

如果DoStuffX（）方法具有通用功能，我会使用枚举。如果没有任何共同点，那么我会使用单独的方法来避免if-else / switch stmts。

多种方法或参数？

7 个答案: