By Chris Douce
In my brief Java career it has happened to me twice. I have found myself faced with the weirdest, most incomprehensible object-oriented source code imaginable. When faced with beasts of such complexity, I have wondered whether there would ever be a sub-discipline called the pathology of programming.
It is quite interesting to view weird code, where the abstractions have grown organically into large classes and coupling between parts of a system have imploded into a web of dependencies. However, having to understand them and ultimately make them function as specified is another matter!
Making loosely-coupled object-oriented code which contains loosely commented and apparently randomly named interfaces and classes is a challenge and the Refactoring book, appearing in the middle of my second bout of Java torture appeared to tell me what I could begin to do to make my horrid software begin to function.
Refactoring is defined as 'a change made to the internal structure of a software system to make it easier to understand and cheaper to modify without changing its observable behaviour'. Using this definition, refactoring could be interpreted to be, in its most simplest form a change to a group of identifiers to make code easier to read. In essence, this is what refactoring is.
Refactoring is not a design methodology, but a redesign methodology which could be described as 'step-wise re-engineering'. The authors emphasise that to make a software system better, small changes should be made. By carrying out a potentially large number of small refactorings the developer can begin to uncover a design that can be not only comprehensible but also reusable and maintainable.
A list of refactorings can be found within the front cover. Some of the refactorings that are described feel like common sense. One of my favourite refactorings is 'introduce parameter object'. For example, if you have a function that requires a large number of parameters used to provide resources that the function requires, these could be bunched together in a single object.
Using an object, this group of parameters can be labelled, and so form a simple and easy to comprehend abstraction, removing jarring commas on a parameter list that may detract from simple comprehension.
Other refactorings that are of interest include, 'collapse hierarchy', 'extract interface' and 'move method' and many others that aim to strengthen boundaries between classes and clarify design.
I suspect that there are many programmers who have discovered and applied refactorings to their own software independently of those proposed by Fowler et. al. Refactoring is, I believe an elegant and powerful idea that I personally have embraced as (currently) a professional programmer.
One of the key contributions I feel is the naming of small groups of software maintenance operations that can be applied. In this way, refactoring has some similarity with Design Patterns, which the authors reference. Like design patterns, the refactoring operations represent a description of a shared abstract concept, potentially increasing the vocabulary of software developers and helping them to communicate not only about the software, but how the software may be used in the future.
Refactoring is not something that is done to a software system once, but continually. As systems evolve and new requirements are introduced, the source code is adapted and class hierarchies changed.
Interestingly, there is little attention focussed towards the topic of documentation. While refactoring occurs, it is likely that the only documentation is the source code itself and, of course, a programmer's paper scribbles used to take load off working memory. During refactoring, comments can become obsolete as fast as member functions as classes are repositioned and renamed. However, this may potentially increase the worth of reverse engineering tools and design recovery tools.
Like so many issues in software development, the use of refactoring may depend upon the domain in which it is applied. I doubt that it will be used by those who have to work with hardware or safety critical systems, where designs are likely to be developed in a systematic and organised way. It is more likely to be applied in cases where the functioning software is rather old and has been 'inherited' by a number of different programmers, each potentially partially comprehending a system.
Also, it would be interesting to study how such a technique would affect programmers working in pairs or groups in comparison to programmers who have had no exposure to the terms and heuristics described within Refactoring.
Refactoring: Improving the Design of Existing Code
by Martin Fowler, Kent Beck, John Brant, William Opdyke and Don Roberts
Addison-Wesley Object Technology Series, 1999
Have you read a book that may be of interest to the PPIG community?
Or maybe you have stumbled across a new journal that may interest us all? If so, send us your reviews.