anti-if campaign

Question

I recently ran against a very interesting site that expresses a very interesting idea - the anti-if campaign. You can see this here at www.antiifcampaign.com. I have to agree that complex nested IF statements are an absolute pain in the rear. I am currently on a project that up until very recently had some crazy nested IFs that scrolled to the right for quite a ways. We cured our issues in two ways - we used Windows Workflow Foundation to address routing (or workflow) concerns. And we are in the process of implementing all of our business rules utilizing ILOG Rules for .NET (recently purchased by IBM!!). This for the most part has cured our nested IF pains...but I find myself wondering how many people cure their pains in the manner that the good folks at the AntiIfCampaign suggest (see an example here) by creating numerous amounts of abstract classes to represent a given scenario that was originally covered by the nested IF. I wonder if another way to address the removal of this complexity might also be in using an IoC container such as StructureMap to move in and out of different bits of functionality. Either way...

Question: Given a scenario where I have a nested complex IF or SWITCH statement that is used to evaluate a given type of thing (say evaluating an Enum) to determine how I want to handle the processing of that thing by enum type - what are some ways to do the same form of processing without using the IF or SWITCH hierarchical structure?

public enum WidgetTypes
{
    Type1,
    Type2,
    Type3,
    Type4
}

...

WidgetTypes _myType = WidgetTypes.Type1;

...

switch(_myType)
{
    case WidgetTypes.Type1:
        //do something
        break;

    case WidgetTypes.Type2:
        //do something
        break;

    //etc...
}

Answer 1

...What?

I can't imagine how to do something like that without some kind of comparison. At all.

An anti-goto campaign I can imagine, but if seems like a pretty damn required control flow structure to me.

Answer 2

The problem is not the 'if' statement, it is the programmers who write bad code.

EDIT: Also, as others have pointed out, you should be using polymorphism (if available) when you are using if statements to check the type of an object, but if statements in and of themselves are very useful and fundamental constructs.

Answer 3

Case statements work great to organize nested ifs.

Answer 4

Switch statements can often be replaced by polymorphism:

abstract class WidgetBase {
  public abstract void DoSomething();
}

class Widget1 : WidgetBase {
  public override void DoSomething() {
    // Do something ...
  }
}

class Widget2 : WidgetBase {
  public override void DoSomething() {
    // Do something ...
  }
}

...

Widget widget = new Widget1(); // Use a factory pattern instead.
widget.DoSomething();

Answer 5

Nice looking site.

Bad idea for a campaign.

Answer 6

You can use the Command Pattern to perform commands based on some value or input.

In answer to your question, you can use a simple lookup table or polymorphism to achieve this, although it places the logic in a different part of the program, which may indeed be the correct thing to do. Here are a couple of examples in C#:

var commands = new Dictionary<WidgetTypes, Action>()
 {
  { WidgetTypes.Type1, () => Console.WriteLine("Type 1") },
  { WidgetTypes.Type2, () => Console.WriteLine("Type 2") },
  { WidgetTypes.Type3, () => Console.WriteLine("Type 3") },
  { WidgetTypes.Type4, () => Console.WriteLine("Type 4") }
 };

commands[WidgetTypes.Type1]();

---

public interface ICommandHandler
{
 void HandleCommand();
}

public class Command1Handler : ICommandHandler
{
 public void HandleCommand()
 {
  Console.WriteLine("Type 1");
 }
}

// ...

var commands = new Dictionary<WidgetTypes, ICommandHandler>()
 {
  { WidgetTypes.Type1, new Command1Handler() },
  { WidgetTypes.Type2, new Command2Handler() },
  { WidgetTypes.Type3, new Command3Handler() },
  { WidgetTypes.Type4, new Command4Handler() }
 };

commands[WidgetTypes.Type1].HandleCommand();

And a bonus reflection method to invoke the method on the current object with the same name:

public void Type1()
{
 Console.WriteLine("Type 1");
}

//...

var type = WidgetTypes.Type2;
typeof(MyClass).GetMethod(type.ToString()).Invoke(this, new object[] { });

Note: don't actually do that

Answer 7

Wow... is this for real?

You could try catch absolutely every exception possible when you go down the wrong execution path until you hit a path of execution that DOESN'T break, but that is FAR worse than if's.

You can use a Command pattern or a Map for when object-orientation and polymorphism is natural, but what if you're dealing with outcomes from user input that are complex and NOT in and of themselves objects?

Answer 8

Replace Conditional with Polymorphism

Answer 9

It depends on how you handle the situation. If you called a different function using the same signature, you could have a dictionary where the key would be the type and the value a delegate pointing to the real handler. Thus you can get rid of the switch and just do

_myDictionary[ _myType ]( param1, ... );

Answer 10

Implementing that idea in a C-like language is very lame... but in a proper functional language with guarded pattern matching is much more idiomatic and a richer way to express conditionals, I dare to add.

Answer 11

I think I understand what they mean. We probably won't survive without if's and switches, but it is true that deeply nested conditional blocks are a pain to read.

An example from my own job: a function to calculate the simulated strain of a shunted wheatstone bridge. This function takes like 5 configuration parameters (which shunt branch, are there any shunt sense lines, supply sense lines, ...), and I wasn't quite looking forward to writing the dispatching routine.

I came up with a templated code structure that allowed me to 'declare' the proper functions (about 30 or so) instead of having to crunch them into one dispatching routine.

This enabled us to very quickly add new configuration parameter cases, and kinda 'copy' the equations from the mathematical overview. Quite a win, really.

Answer 12

Don't worry about the simple if statement, or the straight forward switch statement.

Worry about this:

1. Horribly nested if statements (the Arrowhead anti-pattern). These things are impossible to read and debug.
2. The if (or case) with a bagilion lines of code in them. "OK, we do this and this.... in this case, and that and that... in that case. Also very hard to read. Almost impossible to test or debug.
3. Super complicated conditions: if (bowl AND KitchenSink OR BathroomTub AND ...). What are you testing for again? Wrap that in a method -- in this case: CanHoldWater().

Answer 13

Polymorphism is the right way to go when the logic must be baked into the classes.

But since many applications these days already interact with their own database, another solution is to use table-based logic. Advantages of using tables:

1. Adjust business logic without recompile.
2. Database instances can share the same code but different logic.

I'm not talking about directly embedding source code in a database varchar() field and compiling it on the fly.

But let's say you have a list of input fields, and for each one, you need to perform (a) some RegEx to scrub the value, and (b) one or more tests to validate the result.

In a code-only world, you would have a subclass for each type of field, each implementing, say, it's own methods called ScrubValue() and Validate().

In a table-based pattern, a single Field class would reach into the database (cached of course) based on a FieldType property and retrieve a set of RegEx search/replace strings, and a list of validation test parameters (minimum and maximum length, regex patterns to match, etc.).

This works well for any situation where the number of subtypes is increasing over time and the logic can be expressed as a set of configurable strings, numbers, etc. rather than having to be directly implemented as code.

Answer 14

Being anti-if is silly.

Sometimes replacing a conditional via polymorphism is the right thing to do, but in those cases it wasn't the if statement that was the true problem. The real problem was working with abstract types in non-abstract ways, i.e., failing to think at level of abstraction of the base class.

Other times it is possible to replace a conditional via polymorphism, but doing so would be a bad idea. The logic that leads you to treat one type different from another may belong in the algorithm itself, not the individual classes. Moving that logic to the classes may cause the classes' code to be overly aware of the context in which they are used.

But most often, an if statement has nothing to do with polymorphism at all. Getting rid of if statements is the wrong goal here.

Being anti-if is silly.

Answer 15

Once your if statements start becoming big and nested, one of the possiblities may be that the number of conditions you have to test has grown. In that case, as you add more conditions to the situation it starts becoming exponentially easier to let some combination of conditions fall through the cracks, and then bam, you've got yourself a bug.

I always thought in cases like these, some kind of truth table would be good. About the closest approximation I can come up though ends up being kind of baffling to the average programmer. It involves assembling all your conditions into a single integer, and then trying to cover every number in the range that creates with either a switch statement or a lookup table.

I'm not sure polymorphism is the right answer for this one though. Anyone got any better ideas?

Answer 16

In Java it's easy to use enums as polymorphic anti-if agents.

public class AntiIf {
  public enum WidgetTypes {
    Type1 {
      public void doSomething() {
        //...
      }},
    Type2 {
      public void doSomething() {
        //...
      }},
    Type3 {
      public void doSomething() {
        //...
      }},
    Type4 {
      public void doSomething() {
        //...
      }};

    public abstract void doSomething();
  }

  WidgetTypes _myType; // set by someone to one of the types.

  public void someFunction() {
    //...
    _myType.doSomething();
    //...
  }
}