扩展课程而不覆盖任何东西：不好的做法？

Question

我正在接手一个旧项目。现在我有一些类的自己的util类，它们覆盖了外部库的的util类。 E.g：

public final class StringUtilsXXX extends org.apache.commons.lang3.StringUtils {
}

这些类根本不会覆盖扩展类的任何方法（并且永远不会在将来）。我觉得很困惑，大多数对自己实现的调用只是委托给超类。这是不好的做法吗？

Answer 1

是。这是不好的做法。为什么它将自己的类紧密地耦合到第三方库的论点。我确定你的前任这样做的原因是，如果他有一天需要更换公共语言，他只需要改变一段代码。他可能是因为从lang2升级到lang3而感到沮丧。

他应该这样做的方法是创建一个StringUtil接口，并编写不同的实现（你可以使用lang2实现一个StringUtil，一个使用lang3甚至可能是一个回退实现的实现）从头开始实现。（如果你需要一些字符串处理，或者你需要使用旧的Java版本编译某些版本，或者其他什么）。

Answer 2

如果您没有覆盖任何内容或在子类中添加任何数据或方法成员，通常不需要。但是，对于将来的占位符，可以使用它。

Answer 3

现在不会受伤。但是如果没有提供额外的行为，那么使用（有）StringUtils应该优先于扩展它。

如果有一个可用于StringUtils的接口，并且您指向您的实现（使用它扩展类实例），那么从可维护性的角度来看它可能仍然有意义（这又取决于您如何实例化它）。

Answer 4

我不认为这是一种不好的做法。有些情况下您可能不想依赖外部库的API，并且您可能希望在客户端（您的）代码和外部库之间构建一个包装层。这样做的原因是您可以控制包装器的API ，而不是外部库的API。

Answer 5

我想从模式的角度来看，他真正做的是一个装饰师。我对这个特定的库一无所知（因为我是.net开发人员）并且它暴露了他应该实现的接口，但我会将问题改为： 是否可以在第三方库上创建装饰器，或者我们应该改为使用适配器。

据我所知，适配器是正确的答案。但是在这里还有一些让我感到困惑的事情：在升级我们给别人的项目升级时，我们难道不应该尽可能地努力破坏合同吗？ “他们”必须引入新的命名空间吗？ 如果他们这样做了，我们是否应该责怪我们的大学黑客代码以维护项目，尽管有其他人怀疑的想法/解决方案？

Answer 6

不..这是一种不好的做法。假设明天org.apache.commons.lang3.StringUtils改变了一些东西（删除了一个方法。虽然它不太可能，但它仍然可以在其他类中发生，特别是对于自定义类），想象它会对你的代码产生什么影响。实际上，您正在将方法与org.apache.commons.lang3.StringUtils紧密耦合。