blog dds

As I refactored a piece of code from an imperative to an object-oriented style I increased its clarity and reusability, but I also trippled its size. This worries me.

The CScout refactoring browser supports a few configuration options for its web-based user interface. Their implementation was simple, but did its job. Its implementation in C-style C++ involved a global variable for the option

static bool show_line_number;

fprintf(fo, "<input type=\"checkbox\" name=\"show_line_number\" value=\"1\" %s>"
  "Show line numbers in source listings<br>\n",
  (show_line_number ? "checked" : ""));

  out << "show_line_number: " << show_line_number << endl;

  in >> val;
  // ...
  if (val == "show_line_number:")
    in >> show_line_number;

As I added more options I found that the code I was writing for each option was repeated, and decided to refactor the option handling into a class hierarchy. I used a base class for storing the common elements, and subclasses for handling different option types, like Boolean options, integers, and strings. Again, nothing fancy. In fact to keep the code brief I kept all the classes in one file, and stashed the existing options as static class members, instead of creating singleton classes.

Nevertheless, after I had finished the exercise I found that I had removed 93 lines of old code and added in its place 351 lines of new code. Given that the effort required to write a program and the number of errors in it are known to depend on the number of lines written, the tripling of my code's size as it became object-oriented is deeply disturbing. I made this refactoring immediately before adding a few more options, so I know I will obtain my return on investment in a few days. However, I wonder: what is the productivity and reliability cost that we pay everyday in languages like Java and C# where (almost) everything has to be an object belonging to a class, and there are no lightweight mechanisms for expressing simpler notions?

Read and post comments