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?
5
The internal behaviour of the various classes is not really relevant. The big question is if a ChunkedDataProcessor cares what kind of IDataReader and IDataWriter it is coupled with.
If a ChunkedDataProcessor can’t work with a ContinuousDataReader, but accepts a IDataReader nonetheless, then you have a problem in your design. It could be regarded as a violation of the LSP, but in my opinion, the ChunkedDataProcessor just accepts the wrong interface.
Assuming there are components in the system that can work with either the continuous or the chunked variants without caring which one it is, I would use a design like this:
interface IDataReader;
interface IContinuousDataReader : extends IDataReader;
interface IChunkedDataReader : extends IDataReader;
class ChunkedDataReader : implements IChunkedDataReader;
class ChunkedDataProcessor {
IChunkedDataReader reader;
//...
};
The IChunkedDataReader interface does not even have to add additional methods, but its existence allows you to impose additional constraints on the implementation that might not be suitable for the more generic IDataReader. In ChunkedDataProcessor you can then use those additional constraints of IChunkedDataReader.
1
For languages that support generics, that is usually an effective means of managing inheritance in parallel with one or more “categories”. For example, your interface might become:
IDataReader<TData>
IDataWriter<TData>
IDataProcessor<TData>
And then you might implement your classes as:
ChunkedDataReader : IDataReader<ChunkedData>
ChunkedDataWriter : IDataWriter<ChunkedData>
ChunkedDataProcessor : IDataProcessor<ChunkedData>
Or you might even declare a single class implementing all of these, such as:
ChunkedDataFile : IDataReader<ChunkedData>, IDataWriter<ChunkedData>,
IDataProcessor<ChunkedData>
Then you could have a single dependent class along the lines of:
class Foo<TData>
{
public Foo(IDataReader<TData>, IDataWriter<TData>, IDataProcessor<TData>) { ... }
}
And this would force all of the instances to operate on the same kind of data at compile time.
Unfortunately, I’m guessing that this would involve considerable redesign/re-architecting in your case, because you haven’t taken the time to define what “chunked data” or “continuous data” really is. That’s the problem – right now you’ve got things in a somewhat more procedural than object-oriented style, you’re naming classes after the things they do instead of the things they are. Verbs and collections of verbs are what interfaces – not classes – are for.
What you have is what’s sometimes called the Anemic Domain Model. You have an important domain concept “chunked” or “continuous” data – but haven’t taken the time to define what that actually is, in a standalone object. Instead, there are just a bunch of procedures (wrapped in interfaces and type-specific implementations) written around it.
If you focus more on what the data is, as opposed to what you might do to the data, then you might find a clean solution even if you don’t have generics in your tool set. But personally, I can’t think of a cleaner way.
4