No Conditionals Please
At the 2007 OOPSLA Conference in Montreal, a professor from New York City was explaining how he taught his introductory computer science classes. Students would be given a problem and they’d go through a number of steps until the solution failed. He found that most of the failures occurred as students became entangled in ever more elaborate conditional statements.
To resolve this problem, he told them they could not use conditional statements, and the general results were both better solutions and better coding. My first reaction in one of the breakout sessions was “No way!” Back in the day, one of my favorite pastimes was working out sort algorithms, and I find it hard to imagine working out even a simple bubble sort without using conditional statements. Other examples quickly came to mind, and I dug in to defend the use of conditional statements from if to switch (and everything in between).
Then he mentioned three magic words: State Design Pattern. This got my undivided attention because of the work I’d done with them and more generally, State Machines. Each class in a State Design Pattern is made up of a set of functions that launch when a certain state in invoked. No if’s in sight. Triggers launch different states, and the state classes provide the context for the particular state. In other words, the triggers just call the state class desired.
Aside from the State Design Pattern, can a decent program be written without a single conditional statement when more than one condition needs to be considered? I think it can be, and I’m beginning to think that much better programs can be developed if conditionals are kept out. To illustrate a simple decision-making process with no conditional statements, the following program has a decision-making process based on user input.
package
{
import flash.display.Sprite;
import fl.controls.Button;
import flash.events.MouseEvent;
public class Unconditional extends Sprite
{
private var men:String;
private var women:String;
private var Button1:Button;
private var Button2:Button;
public function Unconditional ()
{
men="Men";
women="Women";
Button1=new Button();
Button1.label=men;
Button1.x=200, Button1.y=150;
addChild (Button1);
Button1.addEventListener (MouseEvent.CLICK,doMen);
Button2=new Button();
Button2.label=women;
Button2.x=200, Button2.y=200;
addChild (Button2);
Button2.addEventListener (MouseEvent.CLICK,doWomen);
}
private function doMen (e:MouseEvent)
{
trace ("Whatever is appropriate for men");
}
private function doWomen (e:MouseEvent)
{
trace ("Whatever is appropriate for women");
}
}
}That was a simple program, and it could have been handled with a single method using a conditional statement.
But It Would Have Been Easier….
In thinking about this, you may be thinking of a long list of cases used in a switch statement or even a simple if...else sequence make a program possible. (I mentioned sort algorithms, and I’m sure you can think of others where you just had to have conditionals.) Often, (in fact usually) it’s easier to use conditional statements than to work out a lot of code that does the same thing. However, no one who took up design patterns was looking for an easier way to create code. In my experience, there’s nothing easy about design pattens except when it comes to the all important task of updating and changing a program. So, because it’s easier probably is not the best argument to preserve conditional statements–at least for readers of this blog.
Why Conditionals?
Rather than ask why not conditionals, I think we need to ask why conditionals? Why indeed? If a programmer wants something to happen given an event, ranging from user input to data from a Web service, the event should trigger the actions directly rather than first filter through a conditional statement. It cuts out a step (the conditional scratching its head) and goes right to the solution. So why even use conditionals? Yes, we’re all used to them, but most of us were used to either sequential or procedural programming before tackling OOP or design patterns. If we can get along without conditionals, and keep a direct link between the state to call an action and the action, it would seem to be a better programming structure. Then, when we want to make changes, the events are not tied into a conditional statement, and we don’t have to untangle the conditional webs we weave.
Comments Please
I’d really like to get some feedback on this idea. If you’re thinking, That’s the stupidest thing I’ve ever head, I’ll save you the trouble–that was my initial thought, and it didn’t really help the discussion. Rather, I’m hoping to find some ideas about this — with or without the State Design Pattern. Mainly, I’m interested in this in the context of design patterns in general; specifically how conditionals or lack of them relate to the different kinds of connections between classes. Do they really get in the way of delegation, composition, aggregation and inheritance? Are they simply a shortcut and add little to good structure? Or not?
Latest Comments