2

我目前正在开发一个基于组件的 API，它是有状态的。顶层组件每个都实现了大约十几个接口。

因此，库存的顶级组件位于抽象实现堆栈的顶部，抽象实现又包含多个混合实现并实现多个混合接口。

到目前为止，一切都很好（我希望）。

问题是基本功能实现起来非常复杂（5 层基类中有 1000 行），因此我不希望组件编写者自己实现接口，而是扩展我的基类（所有锅炉车牌代码已经写好了）。

因此，如果 API 接受接口而不是对我希望组件编写者扩展的抽象实现的引用，那么我将面临实施者不会执行其他代码区域所要求和假定的验证的风险。

因此，我的问题是，有时使用抽象实现引用而不是对其实现的接口的引用来参数化 API 方法是否有效？

您是否有一个使用这种技术的设计良好的 API 的示例，或者我是否试图说服自己采用不好的做法？

4

1 回答 1

1

到目前为止，一切都很好（我希望）。

不完全的。实现十几个接口并不是一个好兆头。但我不知道如何重组，或者是否有可能，因为我不知道代码。

因此，我的问题是，有时使用抽象实现引用而不是对其实现的接口的引用来参数化 API 方法是否有效？

很少，是的。例如（Java）：

  • JSF：javax.faces.context.FacesContext是抽象的，但作为参数传递。
  • EL：javax.el.ELContext- 同上。
  • AWT：java.awt.Image- 同上。

但无论如何，我会说不。将开发人员限制在实现上是不好的。他们可能希望提供一个不应执行任何上述验证的模拟，或者将使用动态代理。

最后，如果你绝对确定你不能重构你的接口，你可以使用尽可能少的抽象类参数。

于 2010-05-09T17:26:55.183 回答