The Verbosity of Object-Oriented Code
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
"Show line numbers in source listings<br>\n",
(show_line_number ? "checked" : ""));
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