A better alternative to incompatible implementations for the same interface?
- by glenatron
I am working on a piece of code which performs a set task in several parallel environments where the behaviour of the different components in the task are similar but quite different.
This means that my implementations are quite different but they are all based on the relationships between the same interfaces, something like this:
IDataReader
-> ContinuousDataReader
-> ChunkedDataReader
IDataProcessor
-> ContinuousDataProcessor
-> ChunkedDataProcessor
IDataWriter
-> ContinuousDataWriter
-> ChunkedDataWriter
So that in either environment we have an IDataReader, IDataProcessor and IDataWriter and then we can use Dependency Injection to ensure that we have the correct one of each for the current environment, so if we are working with data in chunks we use the ChunkedDataReader, ChunkedDataProcessor and ChunkedDataWriter and if we have continuous data we have the continuous versions.
However the behaviour of these classes is quite different internally and one could certainly not go from a ContinuousDataReader to the ChunkedDataReader even though they are both IDataProcessors. This feels to me as though it is incorrect ( possibly an LSP violation? ) and certainly not a theoretically correct way of working. It is almost as though the "real" interface here is the combination of all three classes. Unfortunately in the project I am working on with the deadlines we are working to, we're pretty much stuck with this design, but if we had a little more elbow room, what would be a better design approach in this kind of scenario?
