Refactoring and Design Patterns

This lab will introduce two of the most important skillsets that software engineers must wield effectively: the ability to improve existing code without impacting its functionality (refactoring) and the ability to recognize commonly encountered software problems that have time-proven solution templates (design patterns).

Refactoring

For a multitude of reasons there is a lot of "bad" code in the world, and software engineers are frequently asked to make it "good". Code refactoring is the disciplined process of taking software code that (for whatever reason) falls short of a lofty idyllic design and gradually reworking it into a significantly better state. This is done by applying simple changes that improve its internal structure step-by-step, while never changing the system's fundamental external behavior. The first step in this process is to identify where the code is lacking. The software engineer Kent Beck coined the term "code smells" to refer to common indicators of software problems. With practice, software engineers become quite adept at picking up on these symptoms and learn when code smells bad. Martin Fowler pioneered the cataloging of common refactoring techniques and many of them directly address frequently encountered smells in code. These refactoring techniques prescribe specific, simple changes that remove the smells. Refer to his Refactoring: Improving the Design of Existing Code for further reading on the topic and a detailed discussion of common refactoring techniques. Note that the book recommends strong unit testing as essential for safely refactoring - we'll omit that from these exercises, opting instead to introduce unit testing in a future lab.

Exercise
As an example of simple refactoring, we'll provide some sample "bad code" with a prevalent smell and ask you to walk through the process of refactoring it.

Checkout the CircleCalc Eclipse project from
https://subversion.assembla.com/svn/ee461l-circlecalcrefactoring/trunk/
and perform the following actions:

Critique the code

identify the most offensive smell
identify potential problems that could be encountered in developing and/or maintaining a system that uses the code as it is written

Identify a refactoring from Fowler's catalog that can be applied to remove the smell
Apply the refactoring to "fix" the code
Describe why the refactored code is better

Design Patterns

Software engineers often encounter familiar problems when designing systems and writing code. This commonality in experience was identified early on by the so-called "Gang of Four" who first extensively cataloged these common problems and a set of time-tested templates for solving them in the seminal work Design Patterns: Elements of Reusable Object-Oriented Software. These (and the many design patterns identified since) help prevent situations where software developers reinvent the wheel over-and-over again. Expert software engineers closely study design patterns and deploy them almost instinctively where appropriate. While design patterns and refactoring are distinct notions, refactoring techniques are often applied so as to improve existing software systems that neglect to structure their internals to utilize beneficial design patterns.

Exercise
Extending our refactoring capabilities, in this exercise we'll again provide some sample "bad code" with a prevalent smell. But here we'll apply refactoring with an eye on moving the code to employ a design pattern.

Checkout the ShapeCalc Eclipse project at
https://subversion.assembla.com/svn/ee461l-shapecalcrefactoring/trunk/
and perform the following actions:

Critique the code

identify the most offensive smell
identify potential problems that could be encountered in developing and/or maintaining a system that uses the code as it is written

Identify a design pattern that's use could improve the code
Identify a refactoring (or set of refactorings) from Fowler's catalog that can be applied to remove the smell and implement the design pattern you identified above
Apply the refactoring to "fix" the code
Describe why the refactored code is better

Reference materials:

Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 2000.
Gamma, Helm, Johnson, Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

Developed with guidance from Miryung Kim

Copyright (c) 2011

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found on the GNU web site here.