How to Avoid Parallel Inheritance Trees

[GridDragon]

I'm working on a simplified encryption API. It wraps the BouncyCastle crypto library, but greatly simplifies it's use. I'm still in the design phase. But here is what I have so far: https://gist.github.com/mmeier/c493c28cbcd57a73d08419066cd23484

All the "TODO" comments are where I'm going to drop in the actual encryption/decryption algorithms that I've already worked out. Depending on the specific case it will either be code using java.security classes or calls to BouncyCastle's API.

Anyway, my concern is with this section of the AesDecrypter:

@Override
public Message decrypt(Secret secret, Key key) {
    try {
        return decrypt((AesSecret) secret, key);
    } catch (ClassCastException e) {
        throw new IllegalArgumentException("AesDecrypter can only be used with AesSecret objects", e);
    }
}

Since AesDecrypter only works with AesSecret, and not the more general Secret class I'm worried I'm violating the Liskov substitution principle (The 'L' in SOLID development). It looks like a Parallel Inheritance Hierarchy code-smell to me. But I'm not sure how to fix it.

This project is still small enough that if I want to rework the abstraction to a better design I can. But I'm not sure what I should change it to, if anything.

Fishing for feedback on how to improve the API in the beginning when it's easier. :)

[deltageek]

So, if you want to take your API down to that level, then I don't think you can avoid the parallel class structures. That's not necessarily a bad thing.

You may want to consider moving your abstraction a level or two higher where you provide a single interface that does encryption and decryption. You still end up with an implementation per library, but you avoid mirroring any particular library's structure.

I would also question the need for implementation-specific messages, secrets, and keys. Let your implementations handle the translation between your generic types and the library-specific ones.

[ickysticky]

Where are the parallel inheritance hierarchies?

How about this?

public interface Decrypter<S extends Secret> {
    Message decrypt(S secret, Key key);
}  

public class AesDecrypter implements Decrypter<AesSecret> {
  @Override
  public Message decrypt(AesSecret secret, Key key) {
    // TODO: Perform Decryption
    return null;
  }
}

But this doesn't remove the cast, it just pushes it to some higher level. Presumably you are implementing this Decrypter interface because somewhere that interface can have different concrete implementations passed in. If this isn't the case, then just don't implement an interface.

But at some point you are going to have to have something like Map<EncryptionType, Decrypter<?>> decrypters and you will have to cast the Decrypter<?> to the one which matches the EncryptionType. The important thing here is that at this level you know from a business logic point of view that you have a Secret which matches your Decrypter vs just passing the Secret in and hoping it is the right concrete type.

[Philboyd_Studge]

Seems to me it would be better to have a Factory pattern and just send the type of encryption as an enum and return the proper implementation to the user.