Extreme Enthusiasm

Summary: cool simple program design lesson on Uncle Bob’s blog

Uncle Bob scrive:

In my previous blog (RubarianNotation) I had posted this little code snippet from a Mad Libs program:

  def translate(text)
    questions_and_text = split_questions_from_text(text)
    answers_and_text = replace_questions_with_answers(questions_and_text)
    answers_and_text.join
  end

The variable questions_and_text held on to a list of strings which alternated between questions and text. The question strings looked like this ((an adjective)), and the text was just raw text. So, for example, if my original document looked liks this

((name of someone in room)) took a ((a noun)) today and ((a past-tense verb)) his back.

We would expect the questions_and_text variable to look like this:

["((name of someone in room))",
" took a ",
"((a noun))",
" today and ",
"((a past-tense verb))",
" his back."]

So this variable holds a list of strings of alternating questions and answers.

I did not find the name questions_and_answers satisfying, and started to think that it would be better to use a name more like list_of_strings_of_alternating_questions_and_answers. This variable name is long, so I thought it might be better to create a set of standard abbreviations like ls_alternating_questions_and_answers. And then I stopped myself and realized that I was just reinventing the horror of Hungarian notation. I took this to mean that my program had a design flaw.

So I refactored the program to improve the design. Here’s the impact of that refactoring on the previous snippet of code:

  def translate(document)
    game = make_game(document)
    game.play(GameContext.new(@asker))
  end

What a difference! Remarkably, the first line of both snippets parses the incoming text into a convenient form. The second line of both processes that convenient form, asking the approriate questions and replacing the questions with the answers. And yet the implication of the names between the two snippets is remarkably different. In the first case they are rife with implementation detail. In the second, they tell you whats going on at an abstract level.

There is a more important difference between the two snippets. In the first we are operating on data structures, which is why we want to identify the structure of those data structures. In the second we are telling objects what to do, which is why we don’t care about the structure of the objects and can focus on their intent instead.

Of course this is just good old OO. But for an old C++/Java/C#-head, like me, this is something of an eye-opener. Ruby has very rich primitive types like lists and maps. You can use them to create lists of lists and maps of lists and lots of other deep and convoluted structures. Indeed, that’s what I had done in the first snippet. I had created a semantically rich data structure composed of a list of strings that alternated between raw text and questions. What I have come to realize is that although slinging these rich data structures around is fun, it’s also bad.

As I said in the previous post, we want our variables to hold objects that we can tell what to do, we don’t want our variables holding data structures that we operate on. If we use the former strategy, then the variable names don’t have to encode the structure of the data. Rather they, coupled with the methods that are invoked against them, let us know what we expect the object to do.

Questo articoletto insegna una cosa preziosa: evitare di passare in giro array e liste. In Java, per esempio, spesso uno si chiede se un dato metodo debba restituire un array, oppure una lista:

  List employees();           // meglio questo
  Employee[] employees();     // oppure questo?
  List<Employee> employees(); // o magari questo?

In molti casi la risposta potrebbe essere nessuno dei tre. Meglio restituire una classe ad hoc:

  Employees employees();

Nel primo caso, il codice per iterare sulla collezione dipende da che tipo di collezione ho scelto.

  // caso array
  Employee[] e = employees();
  for (int i=0; i<e.length; i++) {
    e[i].printSlip();
  }
  // caso lista
  List e = employees();
  for (Iterator i=e.iterator(); i.hasNext(); ) {
    ((Employee) i.next()).printSlip();
  }

Potrei addirittura essere tentato di codificare il tipo della variabile “e” nel nome: empList, empArray. Brutto no? Usando la classe ad hoc invece abbiamo:

  Employees e = employees();
  e.each(printSlip);

o addirittura

  employees().each(printSlip);

dove “printSlip” è un oggetto di un’altra classe ad hoc. (Scuse a Francesco Cirillo per avere copiato il suo esempio!)

Questo principio di design è un caso particolare di un principio più generale che consiglia di evitare setters and getters. Ad esempio è brutto

  return rectangle.width() * rectangle.height();

Molto meglio mettere dentro la classe Rectangle un metodo per calcolare l’area:

  return rectangle.area();

In questo modo il nostro codice non si interessa più alle viscere dell’oggetto che riceviamo, ma delega il comportamento all’oggetto stesso. Questo codice continuerà a funzionare anche se gli passiamo un oggetto che rappresenta un cerchio, purché quest’oggetto risponda al messaggio “area”.

Il duo pragmatico ha coniato questo slogan: Tell, Don’t Ask. Non chiedere a un oggetto cosa contiene. Digli di eseguire la sua operazione.

This entry was posted on 22 October 2006 at 17:19 and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.