5.1 - Separation of Concerns

The first technique we’ll use is a special case of separation of concerns. Specifically, here we’ll strive to separate the pure code that contains the core logic of the system we are building from the impure (but necessary!) code that handles all the bits and pieces we need to actually use it, usually involving user interaction, database persistence and similar.

Let’s illustrate this with an example. We’ll write a program that lets the user input a number, calculates the factorial of that number and then shows a message with the result.

We’ll start by ignoring the whole user interaction and write the pure function that calculates the result:

function factorial(n){
  if(n < 0){
    return NaN;
  }
  let result = 1;
  while(n >= 1){
    result = result * n;
    n = n - 1;
  }
  return result;
}

And then, since it is a pure function we can test it very easily trying out some possible input values and see what results they produce:

factorial(0) == 1;
//=> true

factorial(1) == 1;
//=> true

factorial(2) == 2;
//=> true

factorial(3) == 6;
//=> true

factorial(4) == 24;
//=> true

factorial(5) == 120;
//=> true

factorial(-5) == 120;
//=> false

factorial(-5) == -120;
//=> false

isNaN(factorial(-5));
//=> true

Now we can write the user interface functions and have that impure code call the factorial function:

function main(){
  let input = prompt("Please enter a number");
  let n = parseInt(input);
  let result = factorial(n);
  alert("The result is " + result);
}

This code snippet will work in a browser based JavaScript shell, e.g. Chrome Console, since it needs the browser for its dialog message support. Also note that the result of prompt is an arbitrary string that just may contain a number. We must parse it before we pass it on to factorial.

When we run main we’ll be given an input dialog box to enter the number:

We enter the number, press OK and get the result:

Ok, so we have the code that solves the problem by neatly separating the pure from the impure part. You may ask yourself if we needed the impurities for something so basic as communication with the user, then why did we even bother with this separation? What did we gain with it?

To answer those questions, I’ll show a counter-example - a completely impure code that does the same thing:

function factorialImpure(){
  let input = prompt("Please enter a number");
  let n = parseInt(input);
  let result;
  if(n < 0){
    result = NaN;
  }
  result = 1;
  while(n >= 1){
    result = result * n;
    n = n - 1;
  }
  alert("The result is " + result);
}

It’s really just the same example, but with all the code lumped together. We only need to run it to see that it’s doing the same thing. However, we lost one thing - we can’t write tests anymore the way we did with the pure version:

//we could do this
factorial(3) == 6;
//=> true

//but we can't do this:
factorialImpure(3) == 6;

Function factorialImpure does not depend on its parameters at all. It depends on the external state, specifically on whatever user enters the dialog box. It also depends on an external action - nothing will happen until user actually presses OK. Likewise, that function does not return any value (the result is undefined). Instead, it produces a side effect - the alert message. The only straightforward way to test it is to manually run it, type different inputs in the dialog and see what happens. Very tedious!

Not only are they more difficult to test, impure functions are also less reusable. Let’s say that we wanted to be able to run our code not in a browser, but in a node shell, where there is no prompt dialog to collect the user input and we want to pass it as a command line argument instead. With our pure and impure code separated, we can reuse factorial and write a new impure wrapper for the shell interface:

function factorial(n){
    if(n < 0){
        return NaN;
    }
    let result = 1;
    while(n >= 1){
        result = result * n;
        n = n - 1;
    }
    return result;
}

function main(){
    //the first arg is the executable, i.e. node,
    //the second one is the source file name
    //and the third (zero-based) is our custom input
    let input = process.argv[2]; 
    let n = parseInt(input);
    let result = factorial(n);
    console.log("The result is " + result);
}

main();

Save this piece of code in a file called factorial.js and try running it with node factorial.js 3:

node factorial.js 3

#=> The result is 120

And we just re-used our pure factorial function without any modification - we got to make all the changes in the side effect heavy user interface function.

We could further extrapolate on this example with different kinds of interactions, e.g. if we had to get the input number from say some REST service using an AJAX call, then calculate the factorial and push it back to some other service, we would just need another input-output wrapper - one that uses AJAX, e.g.

By separating the core logic from the input output code, we managed to keep the core code pure, which made it more easily reusable, testable and generally better to work with. And yet, we still got to have the necessary side effects in our code. It’s all right there, it’s just neatly sorted in one spot rather than interleaved throughout the code.