Return to Answer

1. Change all of those "magic constant" Strings to meaningfully named constants. What the heck is "FLG"?
2. Then change all the meaningless action names. "Action.AC006" is not a useful name.
3. Change the meaningless comments from "//20", "//30"... (unless these are somehow clear to somebody working on the project) They don't seem to match up with the ACxxx numbers.

Only then try some of the refactorings mentioned in the other answers. Refactoring garbage in leads to refactored garbage out. :-)

And Another Thing Regarding OOP

Other than the value of tmp.b, all of the if statements involve the in object. (Unless I missed one...) Tell Don't Ask suggests that the decide() method, however it gets rewritten, be moved to the in object. e.g.

public Action decideAction(String whateverTmpBReallyMeans);

This may or may not make sense (or even be possible) in your project, but it's worth considering.

1. Change all of those "magic constant" Strings to meaningfully named constants. What the heck is "FLG"?
2. Then change all the meaningless action names. "Action.AC006" is not a useful name.
3. Change the meaningless comments from "//20", "//30"... (unless these are somehow clear to somebody working on the project) They don't seem to match up with the ACxxx numbers.

Only then try some of the refactorings mentioned in the other answers. Refactoring garbage in leads to refactored garbage out. :-)

And Another Thing Regarding OOP

Other than the value of tmp.b, all of the if statements involve the in object. (Unless I missed one...) Tell Don't Ask (or see this SO answer) suggests that the decide() method, however it gets rewritten, be moved to the in object. e.g.

public Action decideAction(String whateverTmpBReallyMeans);

This may or may not make sense (or even be possible) in your project, but it's worth considering.

1. Change all of those "magic constant" Strings to meaningfully named constants. What the heck is "FLG"?
2. Then change all the meaningless action names. "Action.AC006" is not a useful name.
3. Change the meaningless comments from "//20", "//30"... (unless these are somehow clear to somebody working on the project) They don't seem to match up with the ACxxx numbers.

Only then try some of the refactorings mentioned in the other answers. Refactoring garbage in leads to refactored garbage out. :-)

1. Change all of those "magic constant" Strings to meaningfully named constants. What the heck is "FLG"?
2. Then change all the meaningless action names. "Action.AC006" is not a useful name.
3. Change the meaningless comments from "//20", "//30"... (unless these are somehow clear to somebody working on the project) They don't seem to match up with the ACxxx numbers.

Only then try some of the refactorings mentioned in the other answers. Refactoring garbage in leads to refactored garbage out. :-)

And Another Thing Regarding OOP

Other than the value of tmp.b, all of the if statements involve the in object. (Unless I missed one...) Tell Don't Ask suggests that the decide() method, however it gets rewritten, be moved to the in object. e.g.

public Action decideAction(String whateverTmpBReallyMeans);

This may or may not make sense (or even be possible) in your project, but it's worth considering.

1. Change all of those "magic constant" Strings to meaningfully named constants. What the heck is "FLG"?
2. Then change all the meaningless action names. "Action.AC006" is not a useful name.

Only then try some of the refactorings mentioned in the other answers. Refactoring garbage in leads to refactored garbage out. :-)

1. Change all of those "magic constant" Strings to meaningfully named constants. What the heck is "FLG"?
2. Then change all the meaningless action names. "Action.AC006" is not a useful name.
3. Change the meaningless comments from "//20", "//30"... (unless these are somehow clear to somebody working on the project) They don't seem to match up with the ACxxx numbers.

Only then try some of the refactorings mentioned in the other answers. Refactoring garbage in leads to refactored garbage out. :-)