你喜欢重复代码而不是实用程序类吗？ [关闭]答案

【问题标题】：Do you prefer repeating code instead of utility classes? [closed]你喜欢重复代码而不是实用程序类吗？ [关闭]
【发布时间】：2019-09-25 03:38:37
【问题描述】：

我们有一个 Java 服务，它处理大量用户上传的文件，以及为不同模型准备这些文件以执行的任务。

一个这样的准备阶段包括覆盖 json 文件中的值。 10 个任务中有 4 个应该这样做。

我创建了一个静态实用程序类，其中包含一个函数来覆盖 json 文件中的值，类似于

public static class ParameterUtils {
   public static String overrideParameter(String originalContent, String key, String newValue) {
     //4 lines of code that overrides this value and return modified content.
   }
}

但是，我的高级开发人员说，这个实用程序类几乎没有任何价值，而我试图保留 DRY 原则。最后我确实摆脱了这个实用程序类，现在覆盖 json 文件中的值的 4 行代码位于 4 个不同的文件中。

你认为从OOP的角度来看这个类和方法不好？为什么？为什么不？

【问题讨论】：

这是一个基于意见的问题，可能会接近但我部分同意您的高级开发人员。我不认为它没有任何价值，但过多的重复代码会降低代码的可读性，因此应该避免，尤其是当有好的替代方案可用时。
这是主观的。但我会使用静态实用程序。也许，将其命名为非常特定于您的应用程序。我们的代码库中有这样的东西。
可能想要一个更完整的示例并发布到codereview.stackexchange.com。确实没有没有例外的规则，所以魔鬼在细节中。
几乎没有提供任何价值 - 直到需要更改。不，我不喜欢重复代码，但可能有比实用函数更好的方法。也许改为创建一个修饰符链
将一堆原始的String 操作方法填充到一个类中（或使用一些基类）当然是有价值的……与分布在整个应用程序中的相同代码的四个实例相比地方。询问他们的职位和薪水，因为他们可能不值得。

标签： java oop utility-method

【解决方案1】：

不，在多个地方复制（稍微复杂的）代码绝对是不好的做法。

DRY 原则说“不要重复自己”。请记住这一点，您不想通过指示计算机多次覆盖此参数来重复自己。

但是，与只有一个方法的静态实用程序类相比，可能有更好的地方放置它。

如果您使用它的 4 个文件都扩展了某个类，则可以将其设置为受保护的静态方法。或者将它放在返回 JSON 字符串的类中。

但是，将 JSON 作为字符串传递似乎有点代码味道，尤其是当您通过字符串操作来操作它时。使用 JSON 库（例如 Jackson 或 org.json）可能是个好主意。如果您使用 Jackson 的数据绑定功能（使用 Jackson 的最流行方式），您将创建一个带有实际 getter 和 setter 的 POJO，Jackson 负责将其转换为 JSON。在 org.json 的情况下，您使用 JSONObject 类，它与 Map<String, Object> 非常相似，并且您可以像使用地图一样对其进行变异，并且可以使用单个方法将其转换为字符串和从字符串转换.

【讨论】：

是的，我们正在使用 JSON 库将 json 文件转换为 Map，更改我们的值，并将其转换回字符串以上传到 S3。谢谢你的回答，对你有帮助。