Is there a case for parameterising using Abstract classes rather than Interfaces?

Question

I'm currently developing a component based API that is heavily stateful. The top level components implement around a dozen interfaces each.

The stock top-level components therefore sit ontop of a stack of Abstract implementations which in turn contain multiple mixin implementations and implement multiple mixin interfaces.

So far, so good (I hope).

The problem is that the base functionality is extremely complex to implement (1,000s of lines in 5 layers of base classes) and therefore I do not wish for component writers to implement the interfaces themselves but rather to extend my base classes (where all the boiler plate code is already written).

If the API therefore accepts interfaces rather than references to the Abstract implementation that I wish for component writers to extends, then I have a risk that the implementer will not perform the validation that is both required and assumed by other areas of code.

Therefore, my question is, is it sometimes valid to paramerise API methods using an abstract implementation reference rather than a reference to the interface(s) that it implements?

Do you have an example of a well-designed API that uses this technique or am I trying to talk myself into bad-practice?

Answer 1

So far, so good (I hope).

Not quite. Implementing a dozen interfaces isn't a good sign. But I can't tell how to restructure, or is it possible, since I don't know the code.

Therefore, my question is, is it sometimes valid to paramerise API methods using an abstract implementation reference rather than a reference to the interface(s) that it implements?

Rarely, yes. For example (Java):

• JSF: javax.faces.context.FacesContext is abstract, but is passed around as parameter.
• EL: javax.el.ELContext - ditto.
• AWT: java.awt.Image - ditto.

But anyway, I'd say no. It is not good to constrain developers to implementations. They might want to provide a mock that should not perform any of the mentioned validations, or would use dynamic proxies.

Finally, if you are absolutely sure you can't restructure your interfaces, you may go with as little abstract class parameters as possible.