空抽象类是一种不好的做法，为什么? [英] 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)空"的原因:休眠.我根本不掌握这个持久化框架.我只是明白接口不能映射到表，出于这个技术原因，类比接口更受青睐.

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.

推荐答案

在我看来，这是创建对象层次结构的结果，该层次结构最终在其最顶层没有任何通用功能.我怀疑直接子类本身是抽象的，或者至少有它们自己的子类.另一种可能性是您的代码有很多 instanceof 函数分散在其中.

Sounds to me like this is the result of creating an object hierarchy 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 likelihood is that your code has a lot of instanceof functions scattered throughout it.

空的最高级别本身并不是什么大问题，但我会检查以确认实际上不存在通用功能.假设它确实存在，我会考虑在父类中提取通用功能.我肯定会留意 instanceof 并认真考虑重构它.有关示例，请参阅 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 functionality actually exists. Assuming it does exist I would look at pulling the common features up in the parent classes. I would definitely keep a look out for instanceof and think seriously about refactoring it. Refer to Refactoring to Patterns (Kerievsky) for examples.

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