java - Performance cost of refactoring similar methods into Strategy pattern? -

i find myself facing lot of similar methods repeating code in projects. general pattern seems (apologies vague code, licensing won't let me provide concrete example):

 public void modifytype1person() {         map<string, ?> parameters = new hashmap<>();         parameters.put("type", "type1");         parameters.put("stringargument", "some name");         editpersonbasedontype(parameters);     }      public void modifytype2person() {         map<string, ?> parameters = new hashmap<>();         parameters.put("type", "type2");         editpersonbasedontype(parameters);     }      public void modifydefaulttypeperson() {         map<string, ?> parameters = new hashmap<>();         parameters.put("type", "othertype");         parameters.put("booleanargument", true);         editpersonbasedontype(parameters);     }      public void editpersonbasedontype(map<string, ?> parameters) {         // assume stuff done         switch (parameters.get("type")) {             case "type1":                 edittype1person(parameters.get("stringargument"));             case "type2":                 edittype2person();             default:                 editothertype(parameters.get("type"), parameters.get("booleanargument"));         }         // assume more stuff done     }      private void edittype1person(string stringarg) {         person person = personservice.getperson(stringarg);         person.edit();         domorethingsfortype1person(person);     }      private void edittype2person() {         person person = personservice.getperson(hardcoded_name);         person.edit();         domorethingsfortype2person(person);     }      private void editothertype( string type, boolean boolarg ) {         person person = personservice.getperson(hardcoded_name);         person.edit()         domorethingsfordefaulttypeperson(person)     } 

the "domorethingsfortypexperson" methods can either similar or not similar, depending on context.

personally, feel strategy pattern or dependency injection used rid of similar code , eliminate need write multiple methods per type, like:

public void modifytype1person() {     editpersonbasedontype(new type1strategy("some name")); }  public void modifytype2person() {     editpersonbasedontype(new type2strategy()); }  public void modifydefaulttypeperson() {     editpersonbasedontype(new defaulttypestrategy("other type", true)); }  public void editpersonbasedontype(typestrategy typestrategy) {     // assume stuff done     typestrategy.doprocedure();     // assume more stuff done }  public interface typestrategy {     public void doprocedure() }  public class type1strategy {     private string stringargument;      public type1strategy(string stringargument) {         this.stringargument = stringargument;     }     public void doprocedure() {         // edittype1person method     }     private void domorethingsfortype1person() {//implementation} }  public class type2strategy {     public void doprocedure() {         // edittype2person method     }     private void domorethingsfortype2person() {//implementation} }  public class defaulttypestrategy {     private string type;     private boolean boolarg;      public defaulttypestrategy(string type, boolean boolarg) {         this.type = type;         this.boolarg = boolarg;     }     public void doprocedure() {         // editothertype code     }     private void domorethingsfordefaulttypeperson() {//implementation} } 

would use first approach or refactored approach? or there better approach general situation? there need concerned cost of instantiating strategy object?

whenever exchange concrete-type branching code (a bunch of if/else statements or switch) abstract , polymorphic, you're typically paying higher cost rarest of exceptions (ex: when icache hits become important), perhaps considerably higher if involve lookup in exchange map.

and typically extensibility in mind can extend original code supports without modifying (ex: avoid fiddling editpersonbasedontype) or modifying much. becomes necessity if it's impossible continue editing such functions until end of time, if behavior should extensible third parties adding plugins extend range of behaviors.

so whether favor extensibility here or performance you, it's worth noting there's typically performance overhead of micro-efficiency sort here. it's worth noting productivity trumps micro-level performance except in tightest, loopiest parts of codebase show in profiler.

so i'd go whatever design fits needs. in example code, i'm assuming it's been simplified on original, , there wouldn't favor going such route 1 place doing switch on possibility of 3 types. smarter solutions smart when they're reducing burden. perhaps original code lot more extensive , becoming maintenance burden broad plans continue extending , extending it, , if so, might worth refactoring polymorphic design.