我目前正在开发一个基于组件的API，它具有很强的状态。顶级组件分别实现了十几个接口。
因此，库存顶级组件位于一堆抽象实现的顶部，这些实现又包含多个mixin实现并实现多个mixin接口。
到目前为止，非常好（我希望）。
问题是基本功能实现起来非常复杂（5层基类中有1,000行），因此我不希望组件编写者自己实现接口，而是扩展我的基类（其中）所有锅炉板代码已经写好了。
如果API因此接受接口而不是我希望组件编写者扩展的Abstract实现的引用，那么我有一个风险，即实现者不会执行其他代码区域所需和假定的验证。
因此，我的问题是，使用抽象实现引用而不是对它实现的接口的引用来分析API方法是否有效？
你是否有一个使用这种技术的精心设计的API的例子，或者我试图将自己说成糟糕的做法？
答案 0 :(得分：1)
到目前为止，非常好（我希望）。
不完全。实现十几个接口并不是一个好兆头。但我不知道如何重组，或者是否可能，因为我不知道代码。
因此，我的问题是，使用抽象实现引用而不是对它实现的接口的引用来分析API方法是否有效？
很少，是的。例如（Java）：
javax.faces.context.FacesContext是抽象的，但作为参数传递。javax.el.ELContext - 同上。java.awt.Image - 同上。但无论如何，我会说不。将开发人员限制为实现是不好的。他们可能希望提供不应执行任何上述验证的模拟，或者使用动态代理。
最后，如果您完全确定无法重构接口，则可以使用尽可能少的抽象类参数。