We have a feature that is currently implemented, let's call it implA.

ImplA works but can't do many things. So we have decided to rewrite it. But we can't just replace it right away, so we will need to go through another implementation, implB, as a temporary solution to do the transition between implA and implC.

Even when implC is available, many people will still be using implA because it relies on hardware that needs to be updated to use implC. Anyway, from there, we will try to use implC anytime possible but we still need to support implA for some time.

This feature is used across the rest of the application, and I'm wondering the best course of action to make is as painless as possible in the code. So we will end up with implA, implB and implC.

I'm wondering if there is a pattern for this, or just a simple solution I don't think about.

I was thinking of wrapping it in a class that would then call the right impl. But my issue is that implC will have many more functionalities and the logic is different than in implA and implB. So I find it difficult to create a common interface for the 3 classes.

What would be the best solution?

  • In other words, implA and implC are not substitutes of each other - they are unique as they are, and the users/programmers need to be aware of it. Questions: (1) Are there graceful degradations that allow implC's new functionality on older hardware? (2) Are the functionalities in implC cohesive enough (i.e. they naturally belong together), or would it be better off if the collection of functionalities are split off into smaller modules?
    – rwong
    May 28 '15 at 19:14
  • Do you need to select implementations at runtime or can you keep distinct branches in source control and produce different build?
    – coredump
    May 28 '15 at 19:32
  • It definitely makes sense to put them together. The functionalities are cohesive and really belong together. It's just they tackle the same with a different approach. And, it has to be decided at run-time.
    – dyesdyes
    May 28 '15 at 20:59

With the details given, i find difficult to justify the need for temporary implementation - ImplB. Anyway, am parking that here.

As all the 3 are implemented for a specific purpose, though there could be added functionality for implC, I believe that there could be a certain abstract type for these 3 - interface or an abstract class. Once that is in place you could use factory pattern to supply the right instance to the caller depending on certain parameter / set of parameters.

Reference: Factory pattern - http://en.wikipedia.org/wiki/Factory_method_pattern

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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