1

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);
    selectedTool.transferCases(allCases);
}




//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?

-2

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.
2
  • 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 – user2957592 Oct 18 '20 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. – Robert Bräutigam Oct 18 '20 at 10:27

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.