Correct architecture when breaking up a class?
I have a question that is more architectural today.
Basically I want to make my classes as easy to maintain and as logical laid out as I possibly can. I currently have one class that is used to do an almost identical operation 3 times. Each time it does something slightly different. The only real differences are that a handful of variables get values assigned slightly differently and one object gets created from a different class. Right now I have a simple class that just takes in a parameter that gets processed by an "else if" ladder to do the appropriate action.
I do this in just a handful of places throughout the code but it seems to make the code a bit slower (even though the class is only called once with the parameter "x" this sort of 'else if' ladder is often contained in a loop that is iterated through lots and lots of times). What should I do to effectively break this up? I imagine eliminating these else-ifs and breaking this thing up would make the class a lot faster and would make it more flexible later should I wish to add other kinds of calls. Otherwise I need to keep extending this else-if or create a case statement to handle all the possibilities in every instance and it is going to get silly.
if (parameter == "x")
// create object needed for the "x"
else if (parameter == "y")
// create object needed for the "y"
Inheritance? This to me seems like the smartest option but I thought I should ask for the input of someone with more experience. Some variables would need to change but realistically most of the logic would remains unchanged between the 3 different calls (x, y and z).
Make an interface? Seems silly because I'm not changing the logic enough to warrant totally open-ended abstract methods. I would need to maintain 3 separate versions (and possibly later more) of the same code.
I hope I have explained myself adequately. If I haven't please let me know what I can do to further clarify.