Monday, August 25, 2014

Facing annihilation: a powerful koan

There has been no new post on this blog for the past two years, and today I would like to explain why. Let me first issue a disclaimer:
  • this post will not be about programming, even though it is still about something you will most probably not learn at school,
  • ignorance is bliss.
For these two reasons, you may prefer avoiding to read the information that follows. 

If you are still with me, let us stride forward: two years ago, I stumbled across an enlightening and yet depressing conference by Guy McPherson. (There are now more up to date presentations of his, see the link section at the end of this post). With the risk of misrepresenting the quality of this 30 minutes talk, densely packed with data, let me try to summarize its main message:
  • global average world temperature increased by 0.85 degree Celsius against pre-industrial level. 
link: http://www.eea.europa.eu/data-and-maps/figures/global-annual-average-temperature-deviations-1850-2007-relative-to-the-1850-1899-average-in-oc-the-lines-refer-to-10-year-moving-average-the-bars-to-the-annual-land-and-ocean-global-average-9
A 0.85 degree Celsius increase
  • In consequence, tremendous impacts are already being felt across the globe, in particular in the northern region: the arctic.
  • So much so, that once frozen organic matter on land (permafrost) is coming back to life, releasing methane in the the process; simultaneously, methane molecules which were once trapped into ice cages (methane hydrates) at the bottom of the ocean are now escaping, moving up and entering the atmosphere.
  • Methane, although shorter lived than carbon dioxide in the atmosphere, is an extremely potent greenhouse gas, thirty times as much.
Methane hydrate or burning ice!
  • We hence find ourselves in the presence of a vicious cycle: global warming triggers methane releases, a strong driver for more warming and so on.
  • Such cycles are called self-reinforcing (or positive) feedback loops in system dynamics. At the time of the video, Guy cites 4 feedback loops, in more recent talks he presents more than 20 of them (admittedly not all of the same importance).
  • Widely accepted, conventional models of global warming (Intergovernmental Panel on Climate Change, United Nations Environment Programme, Hadley Center for Meteorological Research, Nasa Goddard Institute for Space Studies...) predict a range of temperature increase going from 1 to 10 degrees Celsius by 2100. 
Slowly melting permafrost
  • As dire as some of these projections may seem, none of them take any of the feedback loops into account. Unfortunately, feedback loops are no small matter: Malcolm Light of the Arctic Methane Emergency Group, declares, probably a bit hyperbolically, in a 2010 paper that methane releases going exponential would lead to the demise of all life on earth by mid-century. He even pinpoints year 2031 for the northern hemisphere.

Incredulous?

Global average temperature increases are, for most of us, completely abstract notions. It may thus seem inconceivable that a difference of a couple (4 to 6) degrees could trigger the full scale extinction of our species. Well, 6 more degrees on top of a scorching summer could certainly translate into even more mega-fires (as in Russia), droughts (as in Australia), crop failures (as in California), nuclear reactor shutdowns (as in France), and cattle death, than with today's mere 0.85°C increase... It could also mean winter mild enough for human pathogens to strive (for instance malaria or parasites).

More importantly, these figures are global average which misrepresent local heterogeneity. As indicated in the image from the climate reanalyzer, March 20 of this year, global world temperature was 0.65 degrees above the 1979-2000 period (which is roughly equivalent to 0.85 degrees Celsius against pre-industrial level, only the baseline differs). Yet on that same day a large part of Russia was witness to a full 20 degrees increase. So the average hides really large swings for some places of the globe.

Even more crucially, we really rather need to consider the impacts at the ecosystem level. With the non-linearity that such complex systems often display, nobody can accurately predict what living conditions a 6 degrees increase will produce for anyone of us.
Guy asserts that it leads to the end of the human experience. To support that claim, he offers several explanation which all boil down to the destruction of our natural habitat:
  • insufficient food supplies: crop protein denaturation could be a consequence of severe heat shocks,
  • impossible thermoregulation: higher temperatures will strain thermoregulation abilities to the limit for mammals as large as humans,
  • no oxygen: if deserts replace forests on lands, and phytoplankton in the ocean is completely wiped out, then our two only sources of oxygen vanish, (for the record, phytoplankton is already 40% depleted in comparison to 1950 levels)
  • global nuclear meltdown: a scenario where several meltdowns triggered by, unplanned for, extreme weather events would raise radiations to unlivable levels for terrestrial organisms.

Dire planetary status

Frankly speaking, I don't know how things will really play out. Again nobody can accurately predict the future, but we can easily observe the trends. So before denial kicks in, I would like to review a few facts (not predictions) which illustrate the gravity of our current predicament:
  • at 400ppm, CO2 levels in the atmosphere are now reaching a level unseen in the last 15 million years. (To put that statement in perspective consider that civilization emerged only 10,000 years ago, Homo Sapiens are only 200,000 years old, while Homo Habilis evolved around 2.3 million years ago.)
  • In fact, since the industrial revolution, we drastically changed the composition of the atmosphere, dumping methane (now topping 1700ppb), nitrous oxide, ozone and even synthetic gases such as chorofluorocarbons (CFC), hydrochlorofuorocarbons (HCFC) halons...
  • Unfortunately, this is an ongoing and worsening trend: carbon dioxide emissions from burning fossil fuels set a record in 2013.
Dumping always more carbon in the atmosphere.
The arctic Death spiral.
  • Forests too are declining. Worst of all, primary forests are cut down. The hunger for fresh agricultural land is unsatiable. Don't you think carbon neutral schemes smell dubious? In any case, climate models most probably over-estimate the extent of future forests and thus their real ability to sequester carbon. Even more devastating: atmospheric pollution, especially ozone, seems to be killing trees worldwide.
  • We are now living a mass extinction of life on earth as reported in this documentary. The population numbers speak for themselves: land animals are down 28% since 1970, marine birds are down 30% since 1995, big ocean fish are down 90% since 1950, freshwater fish are down 50% since 1987, marine animals are down 28% since 1970 and songbirds are down 50% since 1950. In the same vein, Paul MacCready, in this excellent TED presentation shows the evolution of the mass of all land based vertebrates. The share of wild animals went from being 99.9% to a tiny 3% in the 10 thousand years since the start of civilization.

Homo Sapiens (?) is winning the war...

This is all without talking about the miserable state of the ocean, soil erosion, natural resources depletion, garbage (such as plastic, radioactivity...) accumulation. And the list just goes on, endlessly... Blinded by desire, we produce what destroys us in far greater quantity than the rest of the creation can instantaneously balance.


Retreating glaciers

Reversing global trends?

There really is no room for optimism. Before that, most of the current global trends fueled by human behavior should first be reversed (in no particular order):
  • Burning of coal and other fossil fuels should be stopped.
  • Our numbers should be decreasing (ideally via access to education, contraception, financial incentives, and equitable one child policy). Population is the multiplier of everything else.
  • Forest cover should be increasing: trees should be planted, forest let to grow.
  • Human population should retreat from cities to be given the opportunity to learn living hard but more sustainable and decent agricultural, pastoral or forager lives.
  • In short, our current economy should come to a halt, thus reducing the count of all our energy-consuming machines: cars, planes, phones, computers...

In addition to these policies directly related to climate change, the following would also most probably be wise to implement:
  • The production of several synthetic substances should be totally banned. In particular products that can not be naturally decomposed in realistic time-frames should never see the light: plastic, composites, nuclear wastes... Similarly, substances that potentially pose irreversible risks to the biosphere, ecosystems, animal or human health should not be put in circulation. Think: CFC, pesticides, most genetically modified organisms, nanoparticles. The burden of proof should be carried by the producers rather than the consumers and any new product considered toxic before being demonstrated as safe.
  • Nuclear power-plants should be shut down before the next radical accident.

Note that there is a 40 years time-lag between carbon emissions and their full impact on the climate. So even if some drastic adjustments were made today, we would have to wait several years before feeling the first improvements.

Predictions

Now is the time for a fun but totally useless game: predictions. Predictions let us exercise and showcase our brain power. They are fun.
But they are really useless too; just another diversion. All the data we have in our hands about the current state of our habitat should be more than enough to convince us of the urgency to change course. Predictions are simply another skillful way of maintaining the status-quo. Build an abstraction, and start endless discussions. Blind ourselves to the present by looking far into a potential future (this works with the past too).

Let me first warn you: my predictions are most probably wrong. Other (Thomas Robert Malthus, Paul Ehrlich, Richard Duncan...), have been somewhat off before. Wrong, but still as valid as any of the so called projections issued by respectable institutes: a world population of 9.6 billion by 2050 according to the United Nations 2013 report? Continued growth in world liquid fuels production up to 2040 according to the US Energy Information Administration? Continued GDP growth for both China, the US and India up to 2030 according to the IMF? I don't think so!

Here is what I rather believe today:
  • Real economic growth has already or will stop before 2020. Resources availability will decline dramatically.
  • Major industrial systems (nuclear reactors, skyscrapers, roads, sewers, water supply systems, electrical grids, computer networks, cities) will fail because of lack of maintenance, nature impacts, or human induced chaos. Large non-tangible systems (health care, government, retirement plans) will break down too. All these symbols of our hubris have continued growth as a first requirement.
  • Human population trends will then quickly reverse. Death rates will increase. Maybe through large scale epidemic or starvation. Great migrations will be unstoppable.
  • Geoengineering will be tried and fail. Technical Progress Raises More and Greater Problems than It Solves. With hindsight, doesn't this axiom stated by Jacques Ellul in his Technological Bluff sound painfully true?
  • By 2040, I expect our numbers to be no more than 1 billion. War for the last habitable places (the poles? underground?) will have started.
  • By the end of this century our species will have gone extinct.
  • In the longer run, will planet Earth then go Venus or still be habitable (by complex life-forms)? I don't know. Does it really matter?

Simple models

These predictions are not based on fancy, complicated mathematical models, rather on simple observations.

First, let us admit our species has a dynamic of its own. Our collective course certainly seems not to be controlled by rational decisions at the individual level. On one hand, various religious beliefs, propaganda, advertisement (should I say automatisms put in place as control mechanisms?) most often trump objective analysis. On the other hand, the most powerful members of our species either have no real control, are extremely cynical, or simply plain dumb. Who knows?
Human behavior displays a lot of inertia. Do smokers stop as soon as they are told the consequences? Why was it necessary for the world fisheries to go into decline before any fishing quota to be put in place? Garret Hardin introduced a simple model called tragedy of the commons to explain this group dynamic. For Nate Hagens, ancient brain characteristics drive our current consumptive behavior. Jay Hanson makes a similar claim. Our fate derives from our very nature.
It thus seems reasonable to assume the human species will try to keep its current dynamic as long as possible: trying to monopolize always more!

Total catch of southern bluefin tune. A quota system was introduced only in 1980.

Our global dynamic collides violently with the limits we are now reaching on every front. We most probably are at our last doubling time.

At this point, forced decline is the only direction. Could the St Matthew reindeer's experiment be a precedent of the speed at which things will unravel for us? Indeed, Ugo Bardi developed a simple model, the Seneca cliff, which shows that staggering maintenance costs and pollution make descent faster than ascension. 

Arx tarpeia Capitoli proxima!
In any case the future will not mirror the last 100 years. Linear extrapolation does not make sense anymore. We are in uncharted exponential, fractured territory. The only elements of comparisons should be other mass extinction events.

What now?

When confronted to this information, people react in a variety of ways. Mostly denial. Changes of this magnitude in such a short time-frame seem unbelievable. Recently, recurrent global catastrophes have started to slowly instill doubt in the dominant narrative which roughly states that in this best of all possible worlds the baron's castle was the most magnificent of all castles. However, extinction is not part of most people's plan yet. It is too hard to accept. It takes time to mentally shift gear. It is hard to reverse lifelong indoctrinations.
I believe denial and hope will progressively shift into despair, shame and anger. The primary reason I am writing today is to go past these feelings. I wanted to state the inescapable facts as clearly as I understand them and then use them as a new inner foundation for the time ahead. Now I am simply left with a challenging koan:
Living with the certainty of near annihilation.







Bibliography

Some hand-plucked links, organized by topics.

Climate change


A slowed down, meandering jet stream has been causing all sorts of bizarre weather patterns in the recent years all over the northern hemisphere. A bit of theory here.

War against the Environment: scale of the Human impact


Understanding the models, predicting the future


Numerous others have made equally dire predictions:
  • For Stephen Hawking, we need to leave the planet before 200 years.
  • James Lovelock expects 80% of humans to perish by 2100.
  • Paleontologist Peter Ward believes global warming will drive us extinct, similarly to previous mass extinction episodes.
  • James Hansen warned against the burning of coal.
  • Some models of IPCC predict a 10 degree rise by 2100, thus making the planet unlivable.

Individual responses


Posted by at 6 comments:
Labels: , , , , ,

Friday, December 28, 2012

Code metamorphosis

In this post, I would like to show through an example, how we can always progressively improve even the most badly written piece of code.
I will start from a somewhat unintelligible program and, step by step, rewrite it until it really pleases the eyes. Doing so, I will preserve its external behavior, which is roughly specified as follows:
The program inputs 3 possibly null strings. It shall interpret them as 2 integers and an operator among +, -, * and /, to then evaluate the expression and display the result.
Any invalid input value is signaled by an appropriate error message.
I am assuming the existence of two library methods:
  • Integer readInteger(String) transforms a string into the integer it represents. This method expects a non-null argument, and returns null on any string which does not correctly parse as an integer,
  • void println(String) prints its string argument on the standard display and terminates with a new line.
Here is our starting point, a program which fulfills the specification:
void calculate(String number1, String operator, String number2) {
  Integer value1;
  Integer value2;
  if (null != number1) {
    value1 = readInteger(number1);
    if (null != value1) {
      value2 = readInteger(number2);
      if (null != value2) {
        if ("+".equals(operator)) {
          println(value1 + value2);
        } else if ("-".equals(operator)) {
          println(value1 - value2);
        } else if ("*".equals(operator)) {
          println(value1 * value2);
        } else if ("/".equals(operator)) {
          if (!new Integer(0).equals(value2)) {
            println(value1 / value2);
          } else {
            println("Division by zero.");
          }
        } else {
          println("Unknown operator: " + operator);
        }
      } else {
        println("Invalid argument: " + number2);
      }
    } else {
      println("First argument is not a valid number.");
    }
  } else {
    println("Missing first argument.");
  }
}
Even though it does the job, this program does not conform my personal aesthetics. Here are the reasons why:
  1. Lack of structure. There is a complete absence of separation of concerns in this monolithic, heavily indented piece. This piece does not express its intent at all, which is really to perform 3 distinct steps: validate and parse its input, then perform the computation, and at last present the result (or an error message) to the user.
  2. Difficult code extensions. Nowadays, programs often need to change their behavior (sometimes drastically and very quickly). So they must be built in a way that allows for future evolutions. For instance, in our case, what if the result needs to be output in a message box rather than the standard output? Or what if, error messages must be dumped separately on the standard error? Multiple lines of code would need to be rewritten. What about handling more complex expressions (with an arbitrary number of operators)? Or replacing all integers with floating points? Similarly, adding error reporting for integer overflows in an uniform way is not a trivial matter. This code is not cut for change, mainly because of its high level of coupling. Adding more functionality will also add to the current mess and lead to code decay.
  3. Hard to read. For such a small task, this code is obviously too hard to understand. It has too many lines of code (length) and a too high level of imbrication (width) for one method. There is no quick way of breaking it down. If kept as it is, maintenance will be costly.
  4. Hidden bug. Ignoring the fact that integer overflows are not avoided, there is another bug in this small piece. Did you spot it? Don't worry if you did not: the process of cleaning it up will, at some point, make this bug surface.
  5. Low testability. I am having a hard time believing that this piece of code can be thoroughly covered with automatic unit tests. In particular, since it is immediately dumped on the console, I can not think of any straightforward way of sensing the output value of the program. The presentation layer is buried too deeply inside the method body to be readily replaced by a fake implementation suitable for testing purposes. This code needs a serious testability improvement.
Believe it or not, despite its chaotic appearance, this program has its own logic. Let me venture an explanation as to why you may encounter this type of code more frequently than desirable:
  1. Single return. Of the epic fight against gotos, remains one bad habit: namely to have only one return point per method. The modern motivation for this rule is to prepare a single break-point for every method when inspecting the program execution using a debugger. Being of the school of thought that running the debugger is already a sign you lost control over your code, I completely disregard this constraint.
  2. Error cases come second. Did you notice that else branches always contained the error cases? This is so that the correct execution can be read first.
  3. Lazy programming. The coder was driven only by the result to compute. He did not care about readability, maintainability, evolutivity or testability at all. In consequence, inputs are parsed when needed, results are output as soon as they become available in total disregard of any program structure.
  4. Low level defensive programming techniques. Were you surprised by the peculiar shape of conditionals? There are two distinct tricks here. First, all calls to equals are made on a constant object, rather than on a variable. (e.g."*".equals(operator)). The rationale being to avoid potential exception to be thrown if the variable happens to be null. On the surface, this may seem reasonable. But I do not like this coding style. Again I believe it shows a lack of control: at every point, the programmer should know whether any variable may be null, or not. If it may then a check should be performed first to handle this case once and for all. If not, then there is no need to worry. It should not be necessary to sacrifice conditional expressions' readability. In any case, later in this post, I will present a programming technique to drastically minimize any null value flowing through the program. Second, in order to ensure a value is not null, this programmer believes that writing (null != x) is preferable to the more straightforward (x != null). This may be true in C, since a small typographical error and the comparison transforms into the assignment x = null. But not so in Java which has a distinct type of boolean. The type-checker protects you.
  5. Grouped variable declarations. All variables used in this method are declared together at the beginning of the method. This is a C habit, which is unnecessary in more modern languages such as Java or C#. It is preferable to let variables have the tightest possible scope since it reduces the burden of understanding the meaning of many variables too early. It also decreases risks of misuses. Some would oppose that variables declared inside a loop are inefficient, since they will be allocated and freed multiple times. I honestly don't know if that is true: optimizing compilers most probably know better. In any case, I highly doubt that any performance bottleneck ever arises from such practice.
We are now almost ready to start refactoring this piece of code. Before we do so, I am going to assume there is a non-regression test suite for this method. It is going to be run at the end of each rewriting step in order to make sure the program external behavior is preserved.

 

Step I: Early return and program intent

First, let us insert some early returns. This will enable us to clearly separate the 3 phases of the program: input validation, computation and presentation. For various reasons, some of you may not like early returns. I do. Anyways, as you will see, in this case, they are only a temporary artifact to disappear in a later refactoring phase. 
void calculate(String number1, String operator, String number2) {
  // Phase 1/3: validate input 
  if (number1 == null) {
    println("Missing first argument.");
    return;
  }
  Integer value1 = readInteger(number1);
  if (value1 == null) {
    println("First number is not a valid integer.");
    return; 
  }
  Integer value2 = readInteger(number2);
  if (value2 == null) {
    println("Invalid integer: " + number2);
    return;
  }
  if (operator == null) {
    println("Missing operator.");
    return;
  }
  // Phase 2/3: computation
  Integer result;
  switch (operator) {
    case "+":
      result = value1 + value2;
      break;
    case "-":
      result = value1 - value2;
      break;
    case "*":
      result = value1 * value2;
      break;
    case "/":
      if (value2.equals(0)) {
        println("Division by zero."); 
        return;
      }
      result = value1 / value2;
      break;
    default:
      println("Unknown operator: " + operator);
      return;
  }
  // Phase 3/3: presentation
  println(result);
}
Here is a list of things we did in this step :
  • Early returns were introduced in order to eliminate error cases as soon as possible. They allowed us to separate the input validation from the rest of the method.
  • An intermediary variable was introduced to store the computation result and separate the presentation layer from the rest of the method.
  • Variable declarations were delayed until needed. Variable initialization is now extremely close from, if not in the same statement as, its declaration.
  • Conditionals were inverted to feel more natural, and the sequence of if/else-if was replaced by a switch statement to make the alternatives more visual.
Admittedly, the program is now longer, but a lot easier to understand. However, in doing so, we also slightly changed the behavior of the program: in the case where the operator is null, the error message became "Missing operator." instead of the previous "Unknown operator: null".

 

Step II: Extract methods and expressions

Let us stop for a moment, and take some time to listen to our code. As I am gaining experience, I am finding this is a worthy practice. Often, the code knows better what it wants to look like. We just have to take notice, handle it softly and follow its lead. Here, the two first large blocks, each starting with a line of comment are eager to become full-fledged methods. In order to increase readability, we will thus extract two methods:
  • Expression parseInput(String number1, String operation, String number2)
  • Integer evaluate(Expression expression)
To do so, we first need to introduce the Expression: an object which encapsulates the output of the parsing phase and which is then evaluated. The expression consists in two integers combined with an operation:
enum EOperation { Plus, Minus, Mult, Div }

class Expression {
  private Integer value1;
  private EOperation operation;
  private Integer value2;
  Expression(Integer value1, EOperation operation, Integer value2) {
    this.value1 = value1;
    this.operation = operation;
    this.value2 = value2;
  }
  public Integer getValue1() { return this.value1; }
  public EOperation getOperation() { return this.operation; }
  public Integer getValue2() { return this.value2; }
}
The code can now easily be rewritten into :
void calculate(String number1, String operator, String number2) {
  Expression expression = parseInput(number1, operator, number2);
  if (expression == null) return;
  Integer result = evaluate(expression);
  if (result == null) return;
  println(result); 
}

Expression parseInput(String number1, String operator, 
                      String number2) {
  if (number1 == null) {
    println("Missing first argument.");
    return null;
  }
  Integer value1 = readInteger(number1);
  if (value1 == null) {
    println("First number is not a valid integer.");
    return null;
  }
  Integer value2 = readInteger(number2);
  if (value2 == null) {
    println("Invalid integer: " + number2);
    return null;
  }
  if (operator == null) {
    println("Missing operator.");
    return null;
  }
  EOperation operation;
  switch (operator) {
    case "+":
      operation = EOperation.Plus;
      break;
    case "-":
      operation = EOperation.Minus;
      break;
    case "*":
      operation = EOperation.Mult;
      break;
    case "/":
      operation = EOperation.Div;
      break;
    default:
      println("Unknown operator: " + operator);
      return null;
  }
  return new Expression(value1, operation, value2);
}

Integer evaluate(Expression expression) {
  Integer result;
  switch (expression.getOperation()) {
    case EOperation.Plus:
      return expression.getValue1() + expression.getValue2();
    case EOperation.Minus:
      return expression.getValue1() - expression.getValue2();
    case EOperation.Mult:
      return expression.getValue1() * expression.getValue2();
    case EOperation.Mult:
      if (expression.getValue2().equals(0)) {
        println("Division by zero.");
        return null;
      }
      return expression.getValue1() / expression.getValue2();
  }
  throw new IllegalArgumentException();
}
There are admittedly now more methods and the code looks even more verbose. But the gain in structure and modularity should be well worth it.
You may be wondering the need to throw an IllegalArgumentException at the end of method evaluate. That is because the compiler does not know this line of code is unreachable (because all enum cases are covered in the switch). It would therefore otherwise emit a compilation error.
Note also, that we did not include any default case in the preceding switch statement. This is done on purpose, so that, if we are to augment the enum with another operation, we will be warned at compile time of all the cases which are not handled.

 

Step III: Exceptions and clean error report

There are two strong code smells left in the previous piece of code:
  • methods parseInput and evaluate both propagate errors up by encoding them into the null return value,
  • error messages are scattered all around.
There is therefore still a high level of coupling between the code which performs the computation task, error handling and the presentation layer. We are going to remedy this situation with the introduction of two exceptions which will respectively signal parse errors and computation errors :
class ParseError extends Exception { }
class DivisionByZero extends RuntimeException { }

void calculate(String number1, String operator, String number2) {
  try {
    Expression expression = parseInput(number1, operator, number2);
    Integer result = evaluate(expression);
    println(result);
  } catch (ParseError e) {
    println("An error occurred while parsing: " + e);
  } catch (DivisionByZero e) {
    println("Division by zero");
  }
}

Expression parseInput(String number1, String operator, 
                      String number2) throws ParseError {
  if (number1 == null) {
    throw new ParseError("Missing first argument.");
  }
  Integer value1 = readInteger(number1);
  if (value1 == null) {
    throw new ParseError("First number is not a valid integer.");
  }
  Integer value2 = readInteger(number2);
  if (value2 == null) {
    throw new ParseError("Invalid integer: " + number2);
  }
  if (operator == null) {
    throw new ParseError("Missing operator.");
  }
  EOperation operation;
  switch (operator) {
    case "+": 
      operation = EOperation.Plus;
      break;
    case "-":
      operation = EOperation.Minus;
      break;
    case "*":
      operation = EOperation.Mult;
      break;
    case "/":
      operation = EOperation.Div;
      break;
    default:
      throw new ParseError("Unknown operator: " + operator);
  }
  return new Expression(value1, operation, value2);
}

Integer evaluate(Expression expression) {
  Integer result;
  switch (expression.getOperation()) {
    case EOperation.Plus:
      return expression.getValue1() + expression.getValue2();
    case EOperation.Minus:
      return expression.getValue1() - expression.getValue2();
    case EOperation.Mult:
      return expression.getValue1() * expression.getValue2();
    case EOperation.Mult: 
      if (expression.getValue2().equals(0)) {
        throw new DivisionByZero();
      }
      return expression.getValue1() / expression.getValue2();
  }
  throw new IllegalArgumentException();
}
I am now fairly satisfied with the current state of the code. We still can and will go a bit further. However, before doing so, we are first going to eliminate a bug and improve test coverage.


Step IV: Fixing a bug and DRY investment

By now, it should be obvious! The parsing phase has a flaw in that it does not check whether the second number may be null. Let us first write a non-regression test which fails:
public void 
test_parseInput_ShouldThrowParseErrorWhenSecondNumberIsNull() {
  try {
    Program program = new Program();
    program.parseInput("0", "+", null);
    Assert.fail();
  } catch (ParseError e) {
  }
}
Please take note how straightforward that test was to write. Writing a similar test harness with the first, monolithic, version of the code, would have been a lot less fluid. It would have required us to first redirect the standard output into a buffer, in order to then assert the correct error message is printed out. Learning how to write such complicated tests is a good exercise. Especially so if you are working with legacy code. But in the long run, it is not worth it. It is largely preferable to rewrite your code in order to make it easily testable.
Fixing the bug would be equally easy. But we are going to make a bit more work than necessary and take this opportunity to further clean up the code. Faithful to the DRY (Don't Repeat Yourself) motto, we will eliminate any repetition by introducing three more methods :
  • ensureIsNotNull(String input) throws a ParseError on a null input,
  • parseInteger(String input) converts the string representation of an integer into its value, and throws a ParseError to signal failure,
  • parseOperation(String input) converts the string representation of an operation into a EOperation.
Here are the methods whose code is modified: 
Expression parseInput(String number1, String operator, 
                      String number2) throws ParseError {
  Integer value1 = parseInteger(number1);
  EOperation operation = parseOperation(operator);
  Integer value2 = parseInteger(number2);
  return new Expression(value1, operation, value2);
}

void ensureIsNotNull(String input) throws ParseError {
  if (input == null) throw new ParseError("Missing input.");
}

Integer parseInteger(String input) throws ParseError {
  ensureIsNotNull(input);
  Integer result = readInteger(input);
  if (result == null) throw new ParseError("Integer expected.");
  return result;
}

EOperation parseOperation(String input) throws ParseError {
  ensureIsNotNull(operator);
  switch (input) {
    case "+": return EOperation.Plus;
    case "-": return EOperation.Minus;
    case "*": return EOperation.Mult;
    case "/": return EOperation.Div;
    default:
      throw new ParseError("Unknown operator: " + operator);
  }
}
I would like to draw your attention to the fact that it is extremely easy (in comparison to a large if else block) to move an unitary instruction such as ensureIsNotNull(number1); around the code. We could for instance, push it up, in an effort to eradicate null values as early as possible. Removing all null values at system boundaries, allows us to safely assume no value can ever be null in the code body. Reducing of that much the risk of null pointer exceptions.

Even more importantly, at the same time we fixed the bug, we limited even more the probability of a similar bug to reappear later. Here, the safeguard consists in having method ensureIsNotNull being called inside method parseInteger. So that, as long as we use this method to parse any other integer, then the same mistake can simply not, by construction, be made.


Step V: Improving testability and seam

Unit tests that assert the correctness of error messages would also be nice to have. These messages may, for instance, be contractual.
One way to do so, would be to redirect the standard output into a buffer (using method System.setOut in Java). Another, simpler way, would be to plug a fake output stream inside the program constructor and write the test as follows: 
public void test_calculate_SignalsDivisionByZero() {
  FakeOutpuStream output = new FakeOutputStream();
  Program program = new Program(output);
  program.calculate("10", "/", "0");
  Assert.assertEquals("Division by zero", 
                      output.getLastPrintedLine());
}
There are two necessary ingredients to make such a test possible. First, a FakeOutputStream, that is a custom OutputStream which really does nothing except store the last printed string. Method getLastPrintedLine can then be called to retrieve this string in order to build the assertion. Second and more importantly, it should be possible to choose the output stream used for all outputs of the program. The best way is to have the program constructor accept this dependency as a parameter. After the previous refactoring steps, methods println is now called in very few different places and it is thus very easy to modify the program to this end: 
class Program {
  private OutputStream output;

  Program(OuputStream output) {
    this.output = output;
  }

  void calculate(String number1, String operator, String number2) {
    try {
      Expression expression = parseInput(number1, operator, number2);
      Integer result = evaluate(expression);
      this.output.println(result);
    } catch (ParseError e) {
      this.output.println("An error occured while parsing: " + e);
    } catch (DivisionByZero e) {
      this.output.println("Division by zero");
    }
  }

  // ...
}
As often, by making the program more testable, we also improved its design. The fact that this piece of code is printing to a stream can now be deduced looking at the constructor signature only. It also becomes easy to plug different kinds of presentation layer, as long as they extend the OutputStream interface.
To inject the output stream program dependency may have seem fairly easy to do here. Sometimes, it may require more work or may not appear so evidently. In any case, it is a very powerful and sane programming technique. This technique supports the stance that we are not building monolithic programs but rather program components. A major coding attitude shift.
As a final note for this section, let me admit that error messages should ideally not be present as constant strings in the program but rather all read from an external resource. But that is for another story.


Step VI: Evaluation the OO way

Let us now wander into the realm of (hard-core) object orientation, and for some of you maybe superfluous bonuses. This next rewrite step originates from a simple observation:
Method evaluate does not need the instance of Program at all, but it rather extensively accesses fields of its unique argument, the Expression.
Consequently the program would surely gain in encapsulation and modularity, if we were to move this method into class Expression. Going a step further, it would make even more sense to dispatch the treatment for each operator into the operations themselves which would relieve the need for the switch statement. It is actually common knowledge that switch statements rigidify object oriented programs. The conventional remedy is a small amount of object inheritance. Here is how it can be done in practice:
interface IOperation {
  Integer evaluate(Integer value1, Integer value2); 
}

class PlusOperation implements IOperation {
  public Integer evaluate(Integer value1, Integer value2) {
    return value1 + value2;
  }
}

class MinusOperation implements IOperation {
  public Integer evaluate(Integer value1, Integer value2) {
    return value1 - value2;
  }
}

class MultOperation implements IOperation {
  public Integer evaluate(Integer value1, Integer value2) {
    return value1 * value2;
  }
}

class DivOperation implements IOperation {
  public Integer evaluate(Integer value1, Integer value2) {
    if (value2.equals(0)) throw new DivisionByZero();
    return value1 / value2;
  }
}

class EOperation {
  public static final PLUS = new PlusOperation();
  public static final MINUS = new MinusOperation();
  public static final MULT = new MultOperation();
  public static final DIV = new DivOperation();
}

class Expression {
  private Integer value1;
  private IOperation operation;
  private Integer value2;

  Expression(Integer value1, IOperation operation, Integer value2) {
    this.value1 = value1;
    this.operation = operation;
    this.value2 = value2;
  }

  Integer evaluate() {
    return this.operation.evaluate(value1, value2); 
  }
}

class Program {
  // ...
  void calculate(String number1, String operator, String number2) {
    try {
      Expression expression = parseInput(number1, operator, number2);
      Integer result = expression.evaluate();
      this.output.println(result);
    } catch (ParseError e) {
      this.output.println("An error occurred while parsing: " + e);
    } catch (DivisionByZero e) {
      this.output.println("Division by zero");
    }
  }
  // ...
}
Each operation has now its own class. These classes all inherit from a common interface which declares an evaluate(String, String) method. To ensure some sort of backward compatibility, we kept an EOperation class, which can be used as an enum by providing several static, final, non-modifiable singleton operations. To be honest, I would never use this trick in an industrial setting. (And don't worry, I will get rid of it in the final refactoring step). For all the reasons exposed in my previous post (see A case against static), this is borderline and unnecessary. But I wanted to make the point that the parsing part of the code need not be changed at all in this refactoring phase (plus, for once, I wanted to please all the memory performance junkies out there: doing so avoids a re-allocation of an IOperation at every call to method calculate).

Without any doubt, this rewrite steps improved the code structure. Note how none of the fields in class Expression escapes the private scope anymore. A sure sign of better encapsulation. Furthermore, modification of the code to handle another operation would be largely more localized than in the initial piece.


Step VII: Ultimate polishing step

Before feeling satisfied, we are going to eliminate the last code smells: the presence of a switch statement and a (fake) enum. To do so I will use yet another trick: that of changing control flow code into data. We will simply put all operations into a hash-map indexed by the string representation of the operation. Then parsing any operator simply amounts to getting the corresponding operation into the hash-map. If no operation is found, then it is a parsing error. As a bonus, since the hash-map will be initialized once in the program constructor, there is really no need for the fake EOperation enum anymore. Here are the two methods which change during this rewrite step: 
class Program {
  private OutputStream output;
  private HashMap<IOperation> operations;

  Program(OuputStream output) {
    this.output = output;
    this.operations = new HashMap<IOperation>();
    this.operations.put("+", new PlusOperation());
    this.operations.put("-", new MinusOperation());
    this.operations.put("*", new MultOperation());
    this.operations.put("/", new DivOperation());
  }
  // ...
  IOperation parseOperation(String input) throws ParseError {
    ensureIsNotNull(operator);
    IOperation result = this.operations.get(operator);
    if (result == null) 
      throw new ParseError("Unknown operator: " + operator);
    return result;
  }
  // ...
}



  





A word on the final code version

Let us have a look at the final version of the code: 



interface IOperation { 
  Integer evaluate(Integer value1, Integer value2); 
}

class PlusOperation implements IOperation {
  public Integer evaluate(Integer value1, Integer value2) {
    return value1 + value2;
  }
}

class MinusOperation implements IOperation {
  public Integer evaluate(Integer value1, Integer value2) {
    return value1 - value2;
  }
}

class MultOperation implements IOperation {
  public Integer evaluate(Integer value1, Integer value2) {
    return value1 * value2;
  }
}

class DivOperation implements IOperation {
  public Integer evaluate(Integer value1, Integer value2) {
    if (value2.equals(0)) throw new DivisionByZero();
    return value1 / value2;
  }
}

class Expression {
  private Integer value1;
  private IOperation operation;
  private Integer value2;

  Expression(Integer value1, IOperation operation, Integer value2) {
    this.value1 = value1;
    this.operation = operation;
    this.value2 = value2;
  }

  Integer evaluate() {
    return this.operation.evaluate(value1, value2);
  }
}

class Program {
  private OutputStream output;
  private HashMap<IOperation> operations;

  Program(OuputStream output) {
    this.output = output;
    this.operations = new HashMap<IOperation>();
    this.operations.put("+", new PlusOperation());
    this.operations.put("-", new MinusOperation());
    this.operations.put("*", new MultOperation());
    this.operations.put("/", new DivOperation());
  }

  void calculate(String number1, String operator, String number2) {
    try {
      Expression expression = parseInput(number1, operator, number2);
      Integer result = expression.evaluate();
      this.output.println(result);
    } catch (ParseError e) {
      this.output.println("An error occured while parsing: " + e);
    } catch (DivisionByZero e) {
      this.output.println("Division by zero");
    }
  }

  Expression parseInput(String number1, String operator, 
                        String number2) throws ParseError {
    Integer value1 = parseInteger(number1);
    IOperation operation = parseOperation(operator);
    Integer value2 = parseInteger(number2);
    return new Expression(value1, operation, value2);
  }

  void ensureIsNotNull(String input) throws ParseError {
    if (input == null) throw new ParseError("Missing input.");
  }

  Integer parseInteger(String input) throws ParseError {
    ensureIsNotNull(input);
    Integer result = readInteger(input);
    if (result == null) throw new ParseError("Integer expected.");
    return result;
  }

  IOperation parseOperation(String input) throws ParseError {
    ensureIsNotNull(operator);
    IOperation result = this.operations.get(operator);
    if (result == null) {
      throw new ParseError("Unknown operator: " + operator);
    }
    return result;
  }
}




First, if you examine conditionals, you will see they are all of the most simple form: if some condition, then throw some exception. Two of them perform input validation, the other two filter results returned by calls to library functions (parseInteger and get from the HashMap can both return null). To sum up, conditionals are all placed at the system boundaries to eliminate unwanted values. It is no coincidence, but rather a choice to perform defense at the perimeter and to fail brutally the earliest possible.

Collecting a few metrics, we can produce the following tables:










Structure
Classes
Methods
Interfaces
Hierarchy depth




First program
1
1
0
0




Last program
6
12
1
1











Complexity
Instructions
Max. instructions/function
Max. imbrication level




First program
26
26
5




Last program
44
7
1











Control flow
if
else
switch
throw
catch




First program
8
8
0
0
0




Last program
4
0
0
3
2











Features
occurrences of null
enum
generic




First program
3
0
0




Last program
3
0
1






Even though this program has more code than the initial version, methods are all very short. The longest one (method evaluate) has only 7 instructions. And the maximum imbrication depth is only one. Taken in isolation, each method does not amount to much, but it is the combination which proves valuable. Testing multiple small methods is easy. So much so, that some developers will not understand the value of such simple tests: seeing it only as an unnecessary repetition of what is already obvious in the code itself. Adding new behavior will be faster and more localized than in the initial monolithic version.

In brief, that is how I like software: minimalist.











Conclusion



In conclusion, I would like programmers to not satisfy themselves with code written in the style of the first sample of this post. Aesthetic matters.

At another level, I would like managers to understand that code quality is desirable, that change is possible. Not only that, but semantics preserving micro-changes are possible too. We performed a drastic code rewrite a step at a time. Each step was fairly small, allowing small commits and minimizing risks. Success is a journey, not a starting point.



Refactoring code is a multi-facet activity. Let me recapitulate the various techniques that were introduced in this post:


    

  • separating concerns (step I),
    • 

  • inverting conditionals and using early returns to make the code more malleable (step I), 
    • 

  • slightly altering the program behavior (sometimes even the specification) to open up more factorization opportunities (step I),
    • 

  • detecting code smells (step II),
    • 

  • replacing comments by well-named methods (step II), 
    • 

  • extracting methods to improve structure (step II),
    • 

  • using exceptions to reduce cognitive load and fail early (step III),
    • 

  • cleaning up code to let bugs surface (step IV),
    • 

  • adding test before fixing bug (step IV),
    • 

  • DRY (step IV), 
    • 

  • taking advantage of fixing bugs to clean up code (step IV),
    • 

  • making code testable (step IV and V),
    • 

  • injecting dependencies as constructor parameters to enable tests (step V),
    • 

  • replacing switch statements with inheritance (step VI), 
    • 

  • increasing object encapsulation by moving methods around (step VI),
    • 

  • converting code into data: switch into hash-maps (step VII),
    • 

  • eliminating null from the system, filtering it at the boundaries, having defense at the perimeter (final word).
    • 















Posted by



at





2 comments:
  


















Labels:
,
,
,
,
,

















          

        

          

        

Thursday, July 12, 2012


          

        










A case against static


















Introduction



Some people believe that all constructs of a programming language have their raison d'être. I am of the opposite school of thought:  I strive hard to write code using extremely reduced, simple and coherent subsets of the language. Because I know this practice is a major factor of code quality. If I was given the choice to remove only one keyword from the Java programming language, I would have no hesitation whatsoever. It would be the static keyword.







I will not dwell into a detailed explanation of the meaning of keyword static. Only that it comes in four flavours: static variables, static methods, static classes and static initialization blocks. Static variables are associated to the class in which they are declared (contrast this to standard fields which necessarily appear in an instance of the class). They can be roughly understood as global variables (with various degrees of visibility). Similarly static methods do not need any class instance to be called, but can not access non-static fields. Static (necessarily inner) classes are somewhat a different story which I prefer not to tell today. (In short, I despise inner classes and ban them in my coding standards). And at last, static initialization blocks are not really worth mentioning: they are simply bug nests to avoid at all costs.







First let me stress the fact that, from a theoretical point of view at least, any program can be written with no static variables nor methods at all (except for the entry point, which is by definition necessarily static). The proof is easy to sketch: group all static variables and methods as non-static members of one huge class. Initialize one instance of this class at the beginning of the program and then pass this instance all over the place for the other classes to use. 



Conversely, note that a Java program with only static variables and methods looks like a C program with modules, but without pointers, structures or unions. Pointers to structures can be somewhat emulated by classes without any methods. Hardcore C programmers must now be grinding their teeth: I am well aware Java does not allow for the power of low level operations such as pointer arithmetic or arbitrary casts (for example from structure to array of characters). Unions however can be recovered with some clever tricks using inheritance.







This brief language analysis underlines the fact that really two orthogonal ways of organizing code are competing within Java:


    

  • pure modular procedural programming (only static methods, and non-static variables in lightweight data objects),
    • 

  • pure dependency-injected object orientation (no static variables or methods).
    • 








In practice, most programs I have encountered are a mix of these two relatively incompatible paradigms. And it feels. So, I am going to make the case, that writing within the pure object oriented fragment of Java is more productive and leads to more robust code.













Problem statement



Let me start by examining some very small code snippets. Although simple, these examples are representative of the use of static methods in real-world programs. 



The most extensive use of static methods is to make a service accessible from any place in the code:


Service.perform();



On the surface, nothing wrong here. However, the truth is that real programs are rarely that simple. In most concrete cases, simply calling a static method such as perform will simply not work. The method will throw some exception, because some internal structure needs to be initialized first. To do so, one needs to call yet another static method first:


Service.initialize();
Service.perform();



This is not the end of the story yet. Method initialize will usually be called once during the setup phase of the application (or maybe worse from another class's initialize method), whereas perform gets called several times, wherever it is required. The two methods, although logically bound, are thus syntactically far apart in the code:


// initialization phase
Service.initialize();
...
// application body
Service.perform();



You may think it is not a big deal. In fact, browsing the documentation of class Service may be sufficient to quickly understand its correct usage. (Even though documentation has an awkward tendency to age very quickly).



But, let us now go just one step further. Consider this piece of code:



Treatment treatment = new Treatment();
treatment.process();



There is a trap in this code. It is hidden from the eyes of the unaware external reader. What matters here, is that somewhere down in the body of method process, lies a call to the same static method Service.perform. This means that method process can be used only under the condition that Service is correctly initialized.


Service.initialize();
...
Treatment treatment = new Treatment();
treatment.process();

Now multiply this pattern many fold, spread it all over your application and you just got yourself a maintenance nightmare. Herein lies the core of the problem with using static: the introduction of hidden dependencies, also called hidden temporal coupling. So called temporal because Service.initialize must be called before and hidden because no indication is visible from the signature of either the constructor of object Treatment or its method process. As a side-note, the book Clean Code, A Handbook of Agile Software Craftsmanship lists hidden temporal coupling among its code smells.








Medusa by Gian Lorenzo Bernini, 1630
Do not let it petrify your code base!		 














Solution





Now contrast the previous code with the pure object oriented alternative. Instead of calling two static methods, one must first create an instance of the Service. Then method perform can be later called on this instance:


Service serviceProvider = new Service();
...
serviceProvider.perform();



The instance of Service constitutes a tangible proof that initialization correctly took place and a guarantee that method perform may be safely called.



Of course, now, the programmer must do the effort to propagate this instance everywhere he wants to use the service. For instance, the serviceProvider could be passed as a parameter of the Treatment constructor:


Treatment treatment = new Treatment(serviceProvider);
treatment.process();



The dependency is made clear by the signature of constructor Treatment. At first, this coding style may, for some, seem more demanding. However it is really more relaxing. There are no surprises. The programmer can safely rely on the signatures of the constructors and methods to ensure and document all dependencies. 







Now that I presented you with the problem and its solution, let me list the multiple reasons why static and in particular hidden temporal coupling is rather bad for your health.








Perseus slaying Medusa
by Laurent-Honoré Marqueste, 1876











The several evils of static







Steep learning curve



Of all the problems related to static, this may seem, in theory, the least worrisome. However, in practice, it will probably consume developpers' time the most. Whenever a coder needs to work on a piece he did not write in the first place, he will have a hard time discovering the implicit dependencies. Unless code is very well documented (and documentation is kept up to date), he will probably need to ask someone more experienced which static methods must be magically called. He will not be able to rely on automatic completion either, since static methods are not carried by the data they operate on.









Costly component reuse



Calling static methods makes code reuse very costly. But that becomes noticeable only at the last minute, when actually trying to extract a piece of code and incorporating it elsewhere. You will have a hard time bringing the result to compile and execute correctly. Only then will it become clear, how heavily the displaced piece of code relied on hidden dependencies. Every single static call must be painstakingly tracked and replaced by some alternative provided in the new execution context. Another solution may seem faster to implement but is even less acceptable: add all the dependencies into the new context. To state it bluntly, highly coupled code can not be cheaply reused.













Increased risks of memory leaks



The deallocation of static variables (and everything that may transitively hold onto them) has to be explicitly taken care of. Programmers familiar with languages having garbage collectors (myself included), tend to easily forget this issue. In our defense, too many details must be handled:


    

  • to write a method which releases memory,
    • 

  • not to forget calling it everywhere it is needed.
    • 




On the opposite, the memory graph held by non-static variables simply frees when program execution leaves the scope. If the documentation is not accurate, programmers may be totally unaware that a static method allocates permanent memory. Which can easily lead to memory leaks. In this case again, the API lies!













Testability issues



Unless you still apply software development techniques from the previous century, you write unit tests. Static methods and variables make unit tests a whole harder to write:


    

  • dependencies must be discovered in order to correctly set the initial state,
    • 

  • memory not released in a test may impact the next one.
    • 




Worst of all, static methods do not provide seams. To perform unit tests, it is often the case that dependencies must be replaced by fake implementations. For instance, suppose you are testing a piece of code which emits orders to a printer:


Component c = new Component();
c.process();



Suppose then that method process performs the printing order with the static call sendPage:


void process() {
    Result result = this.doSomething();
    Page pageToPrint = this.presentResult(result);
    Printer.sendPage(pageToPrint);
}



You would rather not empty another printer ink cartridge every time the test suite is executed. However, there is no easy way to change the behavior of method sendPage for the duration of the test only. One way, which I clearly do not recommend, would be to add yet another static method setImplementation to class Printer. Then the test would go like this:


FakePrinter fakePrinter = new FakePrinter();
Printer.setImplementation(fakePrinter);
Component c = new Component();
c.process();



The much more straightforward solution is to have the constructor for Component depend explicitly on an interface of a printer, which may either be the real Printer (in production code) or a fake (in test code).


FakePrinter fakePrinter = new FakePrinter();
Component c = new Component(fakePrinter);
c.process();



Other examples in the same vein could include a logger whose state you would like to check, the queue of a thread runner which you would like not to fill, files which you would rather not create...









Some hard to track bugs



Static methods and variables are source of bugs of the hard kind. Let me simply illustrate with a real case I once stumbled upon. The application had a configuration service implemented with static methods. In order to retrieve the string value of a property, one would call:


String Configuration.getValue(String key);



The service also had an initialization method:


void Configuration.initialize(InputStream file);



Initialization would read all the configuration key-value pairs present in the input stream and fill a hash table. Calling getValue after initialization would return the property configured by the user. However, calling getValue before would return some default value (most of the time adequate but possibly different from the user's wish). Obviously method Configuration.getValue was called all over the place, even in the program initialization phase. So after some code refactoring, I had unknowingly moved a call to getValue method before the initialization phase. This bug was found very late because no regression test was done on this particular value, and everything seemed to work fine with the default value. It also took some time to pinpoint the root cause of the problem.



Without static, this problem can simply not arise:


Configuration configuration = new Configuration(InputStream file);
...
configuration.getValue("some-key");



Simply because one must first hold an instance of Configuration in order to be able to read some configuration value. And the configuration file is necessarily read when calling the constructor. This category of bugs is a classical consequence of hidden temporal coupling. 



Similarly, memory leaks may also cause costly bugs, found late in the development cycle.











Architecture erosion



Static methods and variables are by their very nature global: they can be easily accessed from anywhere in the application. Pressed by time, developers may be tempted to use these handy static methods without paying their true cost upfront: carefully thinking about the overall architectural logic. Doing so, they introduce additional, hidden, dependencies. The application architecture quickly decays.











Unnecessary coupling



What you don't see, doesn't bother you... until it hurts you. Hidden coupling is bad, because it is hidden. So you won't spend time auditing dependencies and cleaning them up. With time, unnecessary coupling will undoubtedly increase without you even taking notice. So removing static methods should be a top priority. It will take time. You will discover unexpected, sometimes frightening links in your application. But at least, once dependencies are explicit, you can work on them: move them around, remove some, divide others... In the end you will get minimally coupled tight and focused pieces of code.











Static propagates static



At last, I am under the impression that static leads to more static. This may be caused by the fact that static methods can not call non-static methods or access instance variables. So when a developer needs to extend the behavior of a static method, he may feel stuck. Instead of trying to remove the static method, he may choose the path of least resistance by simply adding more static methods or fields. He will then gradually encounter more difficulties writing truly object-oriented code. For instance inheritance will not be possible. He will make more data public, losing encapsulation. He will write more code like this:


A.fill(b);
A.process(b);
A.print(b);



At this point, he ends up being trapped in a C style of programming where objects are used as passive data-structures.















Acceptable uses of static



For the sake of balance, there are, in theory, some harmless uses of static. They all obey two conditions:


    

  • no hidden temporal coupling,
    • 

  • no global mutable state. 
    • 




In other word stateless. Let me list all the examples that I can think of.









Constants 



When final, static variables are acceptable. Strings, integers fall under this category. However, non literal final data-structures (such as hash tables) are not, since their content varies throughout the life of the application. Hand-crafted enums, implemented as several constant objects are also valid. Loggers may be admissible, even though static loggers become a problem as soon as you wish to mock them for testing purposes.









Fresh results



Static methods which return a new result every time are benign. They often provide alternative constructors. For instance the Matrix class may have a default constructor with only zeros as well as a static method identity to build a matrix with its diagonal filled with ones. Careful though, because singletons with global mutable state are only one step away. So, in this particular case I would rather have an instance of a MatrixFactory with a non-static buildIdentityMatrix method. 



By the way, about singletons, Misko Hevery wrote a very well-thought and exhaustive piece underlining their dangers here.









Pure methods



Static methods which work only on the state carried by their arguments are also in theory non-lethal. A nice concrete example being the several assertion methods provided by the Junit framework (say for instance Assert.assertEquals). However, most of the time, having such methods is a sign of bad design. The method should be carried by the object it modifies. The only acceptable exception could be final (sealed in C#) objects, whose behavior can not be modified by inheritance. 



But even in this case, I would either build a manager or encapsulate rather than add static methods. In C#, there is also always the solution of extension methods. But are they a good thing? For lack of experience with this language construct, I haven't made up my mind yet.













Program entry point



Whether you like it or not, you can't escape the fact that the program entry point in either C# or Java is a static method!










Head of Medusa
by Peter Paul Rubens, 1617
Let her rest in peace!











Conclusion



For the notable exception of the program entry point and literal constants, all uses of the static keyword should be banned. At first static methods and variables may seem convenient; especially for lazy programmers. But the cost is simply too high: hidden temporal coupling will rot away your program. The consequences range from a steep learning curve, decreased reusability, poor testability to rigid design. The alternative is to explicitly trace dependencies with object instances which are propagated through the constructors or methods parameters. In return, the signature of each class naturally documents all its dependencies.










Posted by



at





1 comment:
  


















Labels:
,
,
,

















        

      









Subscribe to:
Posts (Atom)