Timeline for Elegant ways to handle if(if else) else
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 23, 2017 at 13:47 | history | edited | Deduplicator | CC BY-SA 3.0 |
added syntax-highlighting
|
| Dec 2, 2011 at 11:34 | comment | added | S.Robins | @Caleb, ProcessFile() is indeed doing one thing. As Karl says in his post, it is using a test to decide which action to take, and deferring the actual implementation of the action possibilities to other methods. If you were to add many more alternate actions, the single purpose criteria for the method would still be met so long as no nesting of logic occurs in the immediate method. | |
| Dec 1, 2011 at 16:40 | comment | added | hugomg | I don't like implicitely passing arguments as instance variables like that. You get full of "useless" instance variables and there are many ways to botch up your state and break the invariants. | |
| Dec 1, 2011 at 5:53 | history | made wiki | Post Made Community Wiki by outis | ||
| Nov 30, 2011 at 19:40 | comment | added | Brian Knoblauch | It's a good goal... That's all I have to say about that... ;-) | |
| Nov 30, 2011 at 19:25 | comment | added | Caleb | +1 It's good advice, but what constitutes "one thing" depends on the current layer of abstraction. processFile() is "one thing," but two things: fileMeetsTest() and either doSomething() or defaultAction(). I fear that the "one thing" aspect may confuse beginners who don't a priori understand the concept. | |
| Nov 30, 2011 at 17:50 | history | answered | Karl Bielefeldt | CC BY-SA 3.0 |