design patterns - anti-if campaign -


I was recently running against a very interesting site which expresses a very interesting idea - anti-if The campaign you can see here. I believe that complex nested if statement is a complete pain in the back. I am currently on a project which was recently some crazy nested IFs that were correctly scrolled correctly. Corrected issues in two ways - We used the Windows Workflow Foundation to address routing (or workflow) concerns, and we implemented all our business rules. In the process of ILOG rules. NET (recently purchased by IBM)! For the most part, this has been our nested pain ... but I think myself how many people do to correct their pain in such a way that the good people in anti IFCampaign () represent a certain scenario By creating many abstract classes for what was originally covered by Nested IF. I wonder if another way to remove this complexity might be to use a IoC container such as Structured Map that can carry out the various bits of functionality and in any way ...

Question: Looking at a scenario where I have a nested complex IF or SWITCH statement that is used to evaluate a certain type of object (the value of an NM To determine) how to handle the processing of that thing by enum - if there are some ways to do the same form of processing without using the IF or SWIFCH hierarchical structure?

  Public Enum WidgetTapes {Type1, Type2, Type3, Type4} ... WidgetTips _myType = WidgetTypes.Type1; ... switch (_myType) {case widget type. Type 1: // break something; Case widget type Type 2: // break something; // etc ...}  

If the problem is not 'if', this programmer That's what bad codes write. Edit: Also, as the others have said, you should use polymorphism (if available) when you are using the statement type of an object , But if statements are very useful and original creation.


Comments

Popular posts from this blog

c# - ListView onScroll event -

PHP - get image from byte array -

Linux Terminal Problem with Non-Canonical Terminal I/O app -