I have to write a code where i have send some data (call it List of cases) using one of two integration tools (Jitterbit, Mulesoft), with possibility of adding more tools in future.

Integration tool being used will be determined runtime. User selects on UI and then integration runs. If user selected "Jitterbit", then it's code will be called. If user selected "Mulesoft", corresponding code will be called.

I am not sure which is better - strategy pattern or use inheritance.

I look at it as strategy pattern, where i plan to do this -

//this code kicks in when user uses UI to select the tool. Lets assume it somehow manages to know which integration tool was selectd, and save it in variable transferToolSelected. And all the cases that needs to be transferred are also somehow present in variable allCases
class buttonClick{
    String transferToolSelected;
    List<Case> allCases;
    transferToolInterface selectedTool = transferToolFactory.getToolClass(transferToolSelected);

//factory class which determines which class to instantiate
class transferToolFactory{
    public static transferToolInterface getToolClass(String transferToolSelected){
        if(transferToolSelected == 'Jitterbit') {
            return new JitterbitTool();
        }elseif(transferToolSelected == 'Mulesoft'){
            return new MulesoftTool();

//Interface that all the classes for integration tools will implement
interface transferToolInterface{
    public void transferCases(List<Cases> allCases);

//actual class for jitterbit logic
class JitterbitTool implements transferToolInterface{
    public void transferCases(List<Cases> allCases){
        //code for jitterbit

//actual class for Mulesoft logic
class MulesoftTool implements transferToolInterface{
    public void transferCases(List<Cases> allCases){
        //code for mulesoft

This way when a third tool comes in future. I will create a new class for it, which implements interface transferToolInterface. And edit the transferToolFactory class to add another elseif

But i see that List of cases being passed to is a common feature among all the tools. So i wonder if i should use inheritance. Maybe have an abstract base class that has variable allCases and an abstract method transferCases.

Rest of the logic could be similar. JitterbitTool and MulesoftTool will extend the base class. transferToolFactory will stay the same.

So which design is better and why?

1 Answer 1


Definitely don't use inheritance. Here are some reasons off the top of my head:

  • Inheritance is actually quite restrictive and limited. By default avoid it.
  • Even if inheritance is used, you should not allow access to internal members of the base-class. This just makes the coupling worse.
  • You are forcing the user classes to use inheritance. Since there only can be one parent class, you take this option from the user class.
  • Creating a "base-class" is actually considered an anti-pattern by some (me included).
  • You could potentially re-use "tool" objects, if the cases are a parameter and not state. This may not be something that you care about. But if the tool has some connection, http client or things like that as state, it may matter.
  • Thank you for your response. Could you elaborate the very last point a bit more? If the cases are a parameter and not state and tool has some connection ... using inheritance might be ok? Is that what you mean? If yes, why would it be OK in that case? Why wouldn't we use interface even then Commented Oct 18, 2020 at 0:57
  • The last one is a reason to make "cases" a parameter instead of state. Because if it is state, you'll need new objects for each invocation essentially, which means you can't use the state for things that are more permanent. Commented Oct 18, 2020 at 10:27
  • A bit late to the party, but not sure why this answer has downvotes. I agree with @Robert here, and there is more than one way to skin a cat. Regardless of the choice (strategy or inheritance) it sounds like you only care that the correct logic is being called for the correct tool. Using inheritance and creating concrete classes for each case only adds complexity & boilerplate. Using strategy and creating concrete logic for each cases minimizes complexity & boilerplate by keeping the transferTool implementation flat (not hierarchical) and localizing the differences to the interface functions. Commented Apr 7, 2023 at 23:06
  • I am not familiar with those integration tools, but imagine mulesoft releases "mulesoft_v2" and it requires new transfer logic. With inheritance do you inherit from the existing mulesoft class or make a mulesoft baseclass to be used in subclasses for each version? Where as with strategy you just setup up mulesoft_v2 interface and be done with it. Commented Apr 7, 2023 at 23:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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