TL;DR Don't use IFs in your code.

Nobody uses GOTO instruction anymore and few programming languages still support it.

We have matured, and confirmed spaghetti code is unmaintainable and error-prone. Structured Programming solved that problem years ago.

We got rid of the sentence thanks to Edsger Dijkstra's incredible paper: Go To Statement Considered Harmful.

The next evolution step will be removing most [IF statements](en.wikipedia.org/wiki/Conditional_(computer...

IFs / Cases and Switches are GOTOs disguised as structured flow.

Our tool will be Object-Oriented Programming principles.

Photo Przemysław Bromberek en Pixabay

The Problem

Most IF sentences are coupled to accidental decisions. This coupling generates ripple effect and make code harder to maintain.

IFs are considered as Harmful as GOTOs.

There's an excellent talk below (If considered harmful: How to eradicate 95% of all your bugs in one simple step - Jules May])

IF sentences violate open/closed principle. Our designs will be less extensible and closed to extension.

What is more, IFs are open doors to even worse problems, like switches, cases, defaults, return, continue and breaks.

They make our algorithms darker and force us to build accidentally complex solutions.

People out of software development cannot explain why we use this branching sentence. This is a code smell.

Solutions

Before we move on and remove IF sentences we should decide if it's an essential one or an accidental If.

To check this out we will look for answers in real world through bijection.

Essential Ifs

Let's see an essential IF statement

class Moviegoer {
  constructor(age){
    this.age = age;
  }
  watchXRatedMovie() {
    if (this.age < 18)
      throw new Error("You are not allowed to watch this movie");
    else
      this.watchMovie();
  }
  watchMovie(){
    //..
  }
}

let jane = new Moviegoer(12);

jane.watchXRatedMovie();
//Throws exception since Jane is too young to watch the movie

We should decide whether to remove this if sentence or not.

We must understand whether it represents a business rule (essential) or an implementation artifact (accidental).

In the case above we will honor our bijection. So we will NOT replace the if.

People In real world describe age constraints in natural language using IFs

Accidental Ifs

Let us dive now into bad IFs.

class Movie {

  constructor(rate){
    this.rate = rate;
  }
}

class Moviegoer {
  constructor(age){
    this.age = age;
  }
  watchMovie(movie) {
    if ((this.age < 18) && (movie.rate == 'Adults Only'))
      throw new Error("You are not allowed to watch this movie");

    //watch movie
  }
}

let jane = new Moviegoer(12);
let theExorcist = new Movie('Adults Only');

jane.watchMovie(theExorcist);
//Jane cannot watch the exorcist since she is 12

The movie rating IF is not related to a real world If but to accidental (and coupled) implementation.

Our design decision was to model ratings with strings.

This is a classic neither open to extension, nor closed to modification solution.

Let's see what happens with new requirements.

class Movie {

  constructor(rate){
    this.rate = rate;
  }
}

class Moviegoer {
  constructor(age){
    this.age = age;
  }
  watchMovie(movie) {
    //!!!!!!!!!!!!!!!!! IFS ARE POLLUTING HERE !!!!!!!!!!!!!!!!!!!!!!!!!!
    if ((this.age < 18) && (movie.rate == 'Adults Only'))
      throw new Error("You are not allowed to watch this movie");
    else if ((this.age < 13) && (movie.rate == 'PG 13'))
      throw new Error("You are not allowed to watch this movie");
    //!!!!!!!!!!!!!!!! IFS ARE POLLUTING HERE !!!!!!!!!!!!!!!!!!!!!!!!!!!

    //watch movie
  }
}

let theExorcist = new Movie('Adults Only');
let gremlins = new Movie('PG 13');

let jane = new Moviegoer(12);

jane.watchMovie(theExorcist);
//Jane cannot watch the exorcist since she is 12
jane.watchMovie(gremlins);
//Jane cannot watch gremlins since she is 12

let joe = new Moviegoer(16);

joe.watchMovie(theExorcist);
//Joe cannot watch the exorcist since he is 16
joe.watchMovie(gremlins);
//Joe CAN watch gremlins since he is 16

We can detect some Code Smells:

1. Code is polluted with IFs.
2. A default statement is missing.
3. New ratings will bring new IFs.
4. The strings representing ratings are not first class objects. A typo will introduce hard to find errors.
5. We are forced to add getters on Movies to take decisions.

The Recipe

Let's fix this mess with these steps:

1. Create a Polymorphic Hierarchy for every IF condition (if it doesn't already exist).
2. Move every IF Body to the former abstraction .
3. Replace IF Call by polymorphic method call.

On our example:

//1. Create a Polymorphic Hierarchy for every IF condition (if it doesn't already exist)
class MovieRate {
  //If language permits this should be declared abstract
}

class PG13MovieRate extends MovieRate {
  //2. Move every *IF Body* to the former abstraction 
  warnIfNotAllowed(age) {
    if (age < 13)
      throw new Error("You are not allowed to watch this movie");    
  }
}

class AdultsOnlyMovieRate extends MovieRate {
  //2. Move every *IF Body* to the former abstraction 
  warnIfNotAllowed(age) {
    if (age < 18)
      throw new Error("You are not allowed to watch this movie");    
  }
}

class Movie {
  constructor(rate) {
    this.rate = rate;
  }
}

class Moviegoer {
  constructor(age) {
    this.age = age;
  }
  watchMovie(movie) {
    //3. Replace IF Call by polymorphic method call
    movie.rate.warnIfNotAllowed(this.age);     
    //watch movie
  }
}

let theExorcist = new Movie(new AdultsOnlyMovieRate());
let gremlins = new Movie(new PG13MovieRate());

let jane = new Moviegoer(12);

//jane.watchMovie(theExorcist);
//Jane cannot watch the exorcist since she is 12
//jane.watchMovie(gremlins);
//Jane cannot watch gremlins since she is 12

let joe = new Moviegoer(16);

//joe.watchMovie(theExorcist);
//Joe cannot watch the exorcist since he is 16
joe.watchMovie(gremlins);
//Joe CAN watch gremlins since he is 16

With this outcome:

1- Code is polluted with IFs.

We should add no more IFs. Extending the model will be enough.

2- A default statement is missing.

In this case default behavior is not needed since exceptions break flow. In many times a Null Object will be enough.

3- New ratings will bring new IFs.

We will address it with polymorphic new instances.

4- The strings representing ratings are not first class objects. A typo will introduce hard to find errors.

This is hidden in Ratings implementation.

5- We are forced to add getters on Movies to take decisions.

We will clear this problem favoring Demeter's Law.

---

Breaking this collaborator chain

movie.rate.warnIfNotAllowed(this.age);

class Movie {
  constructor(rate){
    this._rate = rate; //Rate is now private
  }
  warnIfNotAllowed(age){
    this._rate.warnIfNotAllowed(age);
  }
}

class Moviegoer {
  constructor(age){
    this.age = age;
  }
  watchMovie(movie) { 
    movie.warnIfNotAllowed(this.age);     
    //watch movie
  }
}
@mcsee

Rating is private so we don't break encapsulation.

As a consequence we are safe to avoid getters.

Applying the recipe to all IF conditions

Now we have the secret formula we can go further and try to remove the essential IF condition related to age.

class Age {
}

class AgeLessThan13 extends Age {
  assertCanWatchPG13Movie(){
    throw new Error("You are not allowed to watch this movie");    
  }
  assertCanWatchAdultMovie(){
    throw new Error("You are not allowed to watch this movie");    
  }
}

class AgeBetween13And18 extends Age {
  assertCanWatchPG13Movie(){
    //No Problem   
  }
  assertCanWatchAdultMovie(){
    throw new Error("You are not allowed to watch this movie");    
  }
}

class MovieRate {
  //If language permits this should be declared abstract
  //abstract assertCanWatch();
}

class PG13MovieRate extends MovieRate {
  //2. Move every *IF Body* to the former abstraction 
  assertCanWatch(age) {
    age.assertCanWatchPG13Movie()    
  }
}

class AdultsOnlyMovieRate extends MovieRate {
  //2. Move every *IF Body* to the former abstraction 
  assertCanWatch(age) {
     age.assertCanWatchAdultMovie()      
  }
}

class Movie {
  constructor(rate){
    this._rate = rate; //Rate is now private
  }
  watchByMe(moviegoer){
    this._rate.assertCanWatch(moviegoer.age);
  }
}

class Moviegoer {
  constructor(age){
    this.age = age;
  }
  watchMovie(movie) { 
    movie.watchByMe(this);  
  }
}

let theExorcist = new Movie(new AdultsOnlyMovieRate());
let gremlins = new Movie(new PG13MovieRate());

let jane = new Moviegoer(new AgeLessThan13());

//jane.watchMovie(theExorcist);
//Jane cannot watch the exorcist since she is 12
//jane.watchMovie(gremlins);
//Jane cannot watch gremlins since she is 12

let joe = new Moviegoer(new AgeBetween13And18());

//joe.watchMovie(theExorcist);
//Joe cannot watch the exorcist since he is 16
joe.watchMovie(gremlins);
//Joe CAN watch gremlins since he is 16

We replaced all IFs. In the later case using Double Dispatch Technique

We used our formula and it worked. But there's a smell of over design.

1. Classes representing Ages are not related to real concepts on our model.
2. The model is too complex.
3. We will need new classes related to new age groups.
4. Age groups might not be disjoint.

We should avoid the last design and set a clear boundary between essential and accidental ifs.

A Good design rule is to create abstractions if they belong to the same domain (movies and ratings) and don't do it if they cross domains (movies and ages).

Do Ifs stink?

According to evidence shown above. We should consider many IFs to be a code smell and tackle them with our recipe.

Why this is happening?

This article (and many others) recommend avoiding most IF sentences. This will be very hard for all developers very comfortable with its usage.

Remember, Laziness and hidden assumptions are very rooted in our profession. We have been (ab)using IFs for decades and our software is not the best version of it.

This is a root cause analysis of a serious SSL defect on IOS caused by a lazy case:

This article's thesis suggests there's a correlation between IFs/Switch/Case and defects.

You should give a try and avoid IF conditionals.

Conclusions

With this simple technique we will be able to remove, in a procedural way, all accidental ifs.

This will make our models less coupled and more extensive.

Null object pattern is a special case of this technique. We will be able to remove all NULLs since:

NULL ifs are always accidental.

Credits

We have been using If removal technique at Universidad de Buenos Aires for several years. Kudos to all my fellow teachers for all the experience we gathered together with it.

---

Part of the objective of this series of articles is to generate spaces for debate and discussion on software design.