Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Pretty sure there's a typo at the beginning of the last paragraph since by your diagram ContinuousDataReader and ChunkedDataProcessor are not both IDataProcessors -- one of them is a IDataReader. But I don't think what you intended to refer to is an LSP violation; e.g. if IDataWriter has two subtypes, they do not have to (and most often, won't be able to) substitute for one another. An LSP violation would be if the subtype actually can't function as an IDataWriter at all. Most OO languages won't allow that to happen in the first place. –  goldilocks Sep 21 '13 at 14:27
    
@goldilocks quite right, well spotted! Fixed it now. –  glenatron Sep 21 '13 at 14:35
    
Do these implementation classes depend on each other, e.g. ChunkedDataProcessor requiring a ChunkedDataReader or something like that? Or is there some other, external component that actually accepts all three interfaces and requires them to be of the same "kind"? There's a simple answer in the case of the former, but you're in big trouble if it's the latter... –  Aaronaught Sep 21 '13 at 16:43
    
@Aaronaught There is, as you correctly infer, a general data processing manager that takes the components and manages their threading and concurrency. That needs the different components to belong to the same family, but -fortunately- a given deployment of the system will only ever use one or the other. –  glenatron Sep 23 '13 at 9:00
2  
Full stop, reverse thrusters... if these components are selected at deployment time rather than runtime then it's almost a non-issue. Have a bunch of preset configurations for your IoC container (you are using one, right?) and tell people to load one and only one. It doesn't really matter if different strategies are incompatible with each other because it can't happen in practice. Incidentally, this is exactly what the Abstract Factory Pattern is for. –  Aaronaught Sep 23 '13 at 22:47

2 Answers 2

up vote 6 down vote accepted

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.

share|improve this answer
    
It does indeed care, which is why I was suspicious of the design in general. –  glenatron Sep 21 '13 at 16:16

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.

share|improve this answer
    
I do have generics available here, so that approach might make for a really nice solution to this type of problem. I don't think in terms of the real system ( which is obviously more complex than what I have described here ) that I have a failure of core object orientation as much as that when we sketched out the design we thought that Chunked and Continuous data were more or less the same thing and in detail it turns out they are quite different. Now caught between requirements and a hard deadline, so this is more guidance for next time. –  glenatron Sep 21 '13 at 17:03
    
Fair enough, I obviously can't assume anything about your implementation or architecture beyond what you've already shown us. It sounds like you might have a project management problem as well. "Caught between requirements and a hard deadline" implies fixed time and fixed scope. If it's also fixed cost (or if it's too late to expand the team or outsource some unfinished functionality) then the only thing you can cut is quality. It's always hard to admit a planning or design mistake, but deadlines often turn out to be more flexible than you're originally led to believe. Just food for thought. –  Aaronaught Sep 21 '13 at 17:08
    
These deadlines, as far as the business are concerned, have flexed quite far enough :) we are in the final straight of a long project and at this point we have to get it finished by a very hard, very short deadline. The project management has been pretty good from the dev side, but requirements came through rather slowly - so basically classic development woes. If I can use this approach to tidy it up before deadline, however, I will. –  glenatron Sep 23 '13 at 8:37
    
If you say so. Remember the old Ninety-Ninety Rule. –  Aaronaught Sep 23 '13 at 23:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.