空抽象类是不好的做法，为什么？ [英] Are empty abstract classes a bad practice, and why?

问题描述

我们的代码库中有几个空的抽象类。我觉得很难看。但除了这个非常愚蠢的原因（丑陋）之外，我应该重构它（例如，进入空接口）吗？

We have several empty abstract class in our codebase. I find that ugly. But besides this very stupid reason (ugliness), should I refactor it (into empty interface e.g.) ?

否则，代码是健壮且经过充分测试的。因此，如果只是出于美学的原因，我会通过并让空的抽象类保持不变。

Otherwise, the code is robust and well tested. So if it's only for a "aesthetic" reason, I will pass and let the empty abstract classes remain.

你怎么看？

编辑：

1）空抽象类，我的意思是：

1) By "empty abstract class", I mean something like :

public abstract class EmptyAbstractClass {}

2） 空虚的原因：Hibernate。我根本没有掌握这个持久性框架。我只是理解一个接口不能映射到一个表，并且由于这个技术原因，一个类比接口更受欢迎。

2) The reason for the "emptiness" : Hibernate. I don't master this persistence framework at all. I just understand that an interface cannot be mapped to a table, and for this technical reason, a class has been preferred to an interface.

推荐答案

听起来像这是创建一个对象层次结构的结果，最终没有任何常见的功能在它的最顶层。我怀疑直接的子类本身是抽象的，或者至少有自己的子类。另一种可能性是你的代码中散布着大量的函数实例。

Sounds to me like this is the result of creating an object heirarchy that ended up not having any common functionality at it's top most levels. I suspect that the immediate subclasses are abstract themselves or at least have subclasses of their own. The other likelyhood is that your code has a lot of instanceof functions scattered throughout it.

空的最高级别本身并不是一个大问题，但我会检查验证实际上不存在共同的功能。假设它确实存在，我会考虑在父类中提取常用功能。我肯定会留意一下，并认真考虑重构它（请参阅Refactoring to Patterns（Kerievsky）的例子）。

The empty topmost level isn't a huge deal in and of itself but I would check to verify that no common functioanlity actually exists. Assuming it does exist I would look at pulling the common features up in the parent classes. I would definately keep a look out for instanceof and think seriously about refactoring it (refer Refactoring to Patterns (Kerievsky) for examples).

这篇关于空抽象类是不好的做法，为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！