在大型软件实现中,通常建议将 API 设计与其实现分开。但是在某个地方,它们必须重新连接(即,实现必须重新连接到 API)。
以下示例显示了 API 设计和通过 INSTANCE 对象调用其实现:
import java.util.List;
public abstract class Separation {
public static final Separation INSTANCE = new SeparationImpl();
// Defining a special list
public static interface MySpecialList<T> extends List<T> {
void specialAdd(T item);
}
// Creation of a special list
public abstract <T> MySpecialList<T> newSpecialList(Class<T> c);
// Merging of a special list
public abstract <T> MySpecialList<? extends T> specialMerge(
MySpecialList<? super T> a, MySpecialList<? super T> b);
// Implementation of separation
public static class SeparationImpl extends Separation {
@Override
public <T> MySpecialList<T> newSpecialList(Class<T> c) {
return ...;
}
@Override
public <T> MySpecialList<? extends T> specialMerge(
MySpecialList<? super T> a, MySpecialList<? super T> b) {
return ...;
}
}
}
有些人会争辩说 API 不应该引用实现代码。即使我们通过单独的文件将 API 代码与实现分开,通常也必须在 API 中导入实现代码(至少是类名)。
有一些技术可以通过使用完全限定名称的字符串表示来避免此类引用。该类用该字符串加载,然后实例化。它使代码更加复杂。
我的问题:将 API 代码与实现代码完全分开或隔离是否有任何好处?或者这只是一个纯粹主义者试图在几乎没有实际好处的情况下达到完美的尝试?
最佳答案
我一直理解将接口(interface)与实现分开的要求意味着您不要将实现的方式与内容混在一起。所以在你上面的例子中,混合 api 和实现意味着在 api 中公开一些特定于 SeparationImpl 如何实现你的 api 的东西。
举个例子,看看迭代是如何在各种集合类中实现的。有更具体的方法可以检索特定集合中的元素(例如,通过 ArrayList 中的位置),但这些方法不会在 Collection
中公开,因为它们特定于具体 ArrayList 的实现方式。
我也见过有大量接口(interface)目录的项目,每个接口(interface)都有一个具体的实现,每个接口(interface)都机械地复制它们具体实现中的每个方法,这看起来像是一个完全没有意义的“假装”抽象,因为它是实际上并没有提供任何逻辑抽象。
关于java - API 和实现之间应该完全分离吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6089885/