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

Posted by Chris on Stack Overflow See other posts from Stack Overflow or by Chris
Published on 2010-05-09T17:17:11Z Indexed on 2010/05/09 17:18 UTC
Read the original article Hit count: 144

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?

© Stack Overflow or respective owner

Related posts about best-practices

Related posts about api