3 ms·
Although I generally agree with the concept the truth is it's not easy to stop using `if` or `switch` completely. By applying rules described in the post you ar
by wst_ 8y ago
Although I generally agree with the concept the truth is it's not easy to stop using `if` or `switch` completely. By applying rules described in the post you are just pushing the problem around. At some point, somehow, a decision must be made which branch to follow. Want to create two methods instead of `if` fine, do it - how are you going to decide which of them to call? You want to use polymorphism, fine, do it - how are you going to decide which class to instantiate? What to use enums with methods on them, fine, how are you going to decide which enum to use? You may say "Oh, I am just deserializing user's input to enum. I don't have to decide." Fine, so you've just pushed decision onto users of your application. Sure, you may use some other methods, especially when you must choose from multiple options (map instead of switch, etc.) but you should always remember - just by avoiding decision making in one place, doesn't mean you've completely eliminated it from business process.
- JustSomeNobody 8y ago>... By applying rules described in the post you are just pushing the problem around. At some point, somehow, a decision must be made which branch to follow. Right, and you should try and make that decision as early and as few times as possible. For example, let's say you work with older systems that have grown. You went from one type of config to two types, so now you have If (configOne) ... else ... scattered all over your code. You can't really get rid of the decision, it has to be made, but you can refactor the code to make the decision only once when the app starts up.
- your-nanny 8y agoAfter all the regularities have been abstracted away, one is left, inevitably, with the messy details.