编写带有大量案例的切换案例代码的最佳设计模式是什么?

时间:2018-07-11 06:11:41

标签: java design-patterns switch-statement

我正在编写代码,我需要编写很多开关案例,每种案例都有一些业务逻辑,这些逻辑基本上是来自mysql db查询的查询。即

String computeResult()
{
    //code to connect to mysql
    switch(x)
    {
       case A:
         //executing some query and return the result after some processing
       case B:
         //executing some query and return the result after some processing
       //15 more such cases ahead...
    }
}

我正在用Java(一种面向对象的语言)编写此代码。
我研究了以下选项:
选项1:将整个业务逻辑写入同一个类的15个单独的方法中,但是接下来我将采用过程语言方式。
选项2:应用策略模式。并创建具有通用代码的基类,然后采用各种不同的策略,每种策略针对单个案例计算结果。这些类的方法的调用仍然存在于computeResult()方法中。但这将引起类爆炸,我的项目将再增加15个类。稍后,如果我需要添加更多案例,则意味着添加更多类,并在computeResult()方法中添加更多案例陈述。
我不知道有什么方法可以避免使用这种切换案例代码,这是一件硬编码的事情,在最大程度上,我可以将这些案例名称放到常量文件中的类映射中。

例如:

HashMap < String, BaseResultComputer > map

只会将案例名称映射到相应的结果计算机实现。因此,只要我们再添加一个实现,就只需要再添加一个类,就必须在该常量文件中进行更改。
请提出最好的设计来解决这个问题。

2 个答案:

答案 0 :(得分:2)

This is a recurring question on StackOverflow, but usually someone has a handful of else-ifs and wants to refactor it。我想指出一点,而不是重复这些问题的答案:

仅因为您使用的是面向对象的语言,并不意味着所有内容都必须转换为设计模式!尝试以使现有复杂性更易于管理而不是增加复杂性的方式对事物进行编码。如果您创建15个充满样板代码和一行业务逻辑的类,那真的比单个switch语句更可取吗?

要牢记的原则:

  1. KISS =保持简单愚蠢。
  2. YAGNI =您不需要它。

答案 1 :(得分:2)

在我看来,在这种情况下,我将使用策略模式,因为我们将在纯Java的Java语言下工作,所以如果我们有很多类,就不用担心,其次该解决方案可以接受同意以灵活,简便的方式进行更新以注入新功能。

相关问题