views:

207

answers:

8

I'm creating an implementation that performs conversion from one form to another.

The design problem I am facing now is whether the Encoder and Decoder API should be in one interface or in separate ones. e.g. Apache MINA uses separate interfaces

I am currently doing something like this:

interface Convertor
{
    A encode( B b );

    B decode( A a );
}

The rationale for putting them in one interface is that you can centralize the implementations and fix any protocol changes in one place. Any thoughts on this ?

+2  A: 

Only thing is that you usually have one code part that will use the decoder and a separate using the encoder. So a change to the encoding part of the interface will force an unnecessary recompile of the decoding part and vice versa.

True for c/c++ etc. with header file include.

Search for solid principles and see Interface Segregation Principle.

Fredrik Jansson
This isn't true for Java.
Yoni Roit
A: 

Well, you could have two separate interfaces, and then another interface which combines them. That would make it easier to be able to declare a single parameter for both, e.g.

private IEncoder encoder;
private IDecoder decoder;

public ThingWhichUsesEncodeAndDecode(IEncoder encoder, IDecoder decoder)
{
    this.encoder = encoder;
    this.decoder = decoder;
}

public ThingWhichUsesEncodeAndDecode(IEncoderDecoder both)
{
    this(both, both);
}

It really depends on how often you envisage using one part but not the other. Most of the time I find that encoding/decoding stuff I need both parts available, so I'd probably just declare one interface with both methods - but it does depend on the exact situation.

Jon Skeet
A: 

Typically you would use them together, but some time not. It depends on what is more natural for you. BTW: If you define them separately you can still use them together e.g.

interface Converter extends Decoder, Encoder { }
Peter Lawrey
A: 

consider not having a separate encoder/decoder interface but instead

interface Encodable
{
    Decodable encode();
}
interface Decodable
{
    Encodable decode();
}
class A implements Encodable;
class B implements Decodable;
Noel Walters
A: 

Depends on the application.

If normally you have an encoder and an decoder in the same binary, one interface is fine. If they are usually separate (e.g. a capture application only encoding, a management application only decoding), use separate interfaces.

peterchen
+1  A: 

The disadvantage of having them in the same interface is that it forces your implementations to be both encoders and decoders in a single class. This may seem reasonable currently, but it may not always be that way. So I would ask myself if this should be a requirement/is desirable ?

krosenvold
I would not decide based on that alone, as the implementation could be composed and just delegate to different classes implementing only the encoding and decoding respectively.
mghie
+4  A: 

Having separate interfaces doesn't mean you can't centralize the implementation. For example you could have one class implement both interfaces. Or each class could reference a common class which implements the protocol.

So what I'd do is have separate interfaces, and at least to begin with, have one class implement both. So the implementation is shared, but user code sees the encoder and decoder as separate and independent concepts.

jalf
+1  A: 

Making them separate is a lot more flexible. If you write separate interfaces you can always combine them into a third interface that you use whenever you need both encode and decode functions.

The reverse is not true. If you write one interface from the start, you lose the flexibility to choose to include only encode or decode functions.

Bill the Lizard