Is there a case for parameterising using Abstract classes rather than Interfaces?
- by Chris
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?
