3 ms·
> And then we end up with unmaintainable systems with a class hierarchy higher than the Empire State. Perhaps, but I would rather have testable code than untes
by revscat 14y ago
> And then we end up with unmaintainable systems with a class hierarchy higher than the Empire State.
Perhaps, but I would rather have testable code than untestable code that is nothing more than a series of unnecessary, nested if blocks. We have all seen code that has a structure like
if (depObj1.isSomething()) {
if (depOboj1.getAttr() == CONST1) {
// Do something
} else if (depObj1.getAttr() == CONST2) {
// Do something different
}
} else if ... {
// repeat with minor differences
}
Most of the time the above structure can be abstracted. Abstracting It also has the benefit of making this code more testable: you don't have to set up many different objects, just one.
The OP is correct: in OO languages if statements are a code smell. Like all smells, though, they are not hard and fast rules, but rather indicators that things could probably be done better. No one, certainly not OP, is recommending abandoning if statements. What he is recommending, and I agree with, is that they can and should be avoided, and certainly not turned to as a primary tool in the toolbelt.
- raverbashing 14y agoIt's irrelevant if you're using ifs or different objects, the number of conditions/tests needed for what you are testing is the same. Now, you could make depObj1 of type Obj1 and Obj2 to replace the if, which may simplify testing because the method is "simpler" in Obj1/Obj2/ObjBase but in the end it isn't! Why? Because your test of Obj1/2 has to take care of their dependency to ObjBase. It's usually a dependency hell, needing lots of workarounds to test properly.
- aardvark179 14y agoI might agree if that type of if statement only appeared at one point in the code, but there're normally several scattered around which all have to be updated when obj3 is introduced. Also introducing a class hierarchy often makes it easier to move responsibilities between objects as the code evolves. For example I recently did some work on a graphics library which had a lot of ifs to do with line and fill styles. By changing those into an inheritance hierarchy I found a couple of places where clauses had been missed and so fixed some bugs, but more importantly when we needed to add new fill styles which were more complicated to draw it became very easy to turn the fill style objects into fillers which had all the responsibility for filling paths, not simply setting the graphics state.
- raverbashing 14y agoYes, there are situations where changing the structure of the code is better than having an 'if' like the example you gave. But this doesn't mean that it's better to completely eliminate ifs
- pacala 14y agoAs long as there is a mechanical transformation from one style to another, this is not abstracting, is merely shifting the syntax. You do introduce more named test points, but you risk of creating too many tests at a too small granularity, that will only slow you down for no good reason. Consider using a code coverage tool to help you navigate all the branches, without explicitly naming them. Keep in mind readability. Jumping around source files is costly on the reader, don't break the flow if you don't have to.