用很多案例编写开关案例代码的最佳设计模式是什么？

Question

我正在编写一个代码，我需要编写很多开关案例，每个案例都有一些业务逻辑，基本上是来自 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

这只会将案例名称映射到相应的结果计算机实现。因此，每当我们再添加一个实现时，我们只需再添加一个类，并且必须在该常量文件中进行更改。
请建议处理此问题的最佳设计。

Answer 1

在我看来，我会在这种情况下使用策略模式，因为我们在 java 下工作，所以不用担心我们会有很多类，这是一种纯粹面向对象的语言，其次该解决方案可以接受未来同意以灵活和简单的方式更新以注入新功能。

Answer 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 = 你不需要它。