Page 248 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes 12.1.3 Documenting Refactoring
The power of refactoring as a method lies in systematically organized documents, which describe
proven techniques for enhancing software safely. In refactoring: improving the Design of existing
code. A refactoring catalogue was used a standard format to represent over 70 frequently needed
refactoring.

Each refactoring has five parts:
• Name: identifies the refactoring and helps to build a common vocabulary for software
developers.

• Summary: tells when and where you need the refactoring and what it does. Summary
helps you to find a relevant refactoring in a given situation. It also includes source code
excerpts or UML diagrams to show a simple before and after scenario.
• Motivation: describes why the refactoring should be done and lists circumstances in which
it should not be used.
• The mechanics part provides a step-by-step description of how to carry out the refactoring.
The steps are as brief as possible to make them easy to follow.
Examples illustrate how the refactoring can be employed in real programs. The catalogue
includes refactoring for composing methods and handling local variables (e.g. Extract Method,
Inline Method, Inline Temp, Replace Temp with Query) as well as for moving features and
organizing data (Move Method, Move Field, Hide Delegate, Replace Data Value with Object,
Replace Type Code with State/Strategy). The catalogue also discusses conditional expressions
(Replace Conditional with Polymorphism, Introduce Null Object), object creation (Replace
Constructor with Factory Method) and generalization (Replace Inheritance with Delegation,
Form Template Method).
Most of the refactoring are quite simple and their name pretty much reveals their intention. In
general, most refactoring are tiny steps that transform traditional procedural designs into more
object-oriented ones. The many insightful discussions are the main substance of the catalogue,
in addition to the concrete instructions on how to refractor in various situations.
As the names of some refactoring suggest, refactoring are quite closely related to design
patterns. A design pattern tells you how to solve a recurring design problem in a disciplined
manner in a given context. Refactoring, on the other hand, guides you to enhance your existing
implementation so that it reflects a better design. Often this “better design” is a design pattern.
So, in many cases, you end up applying a set of refactoring to turn a piece of ad hoc code into
an instance of a design pattern.

Refactoring are very useful in developing efficient and flexible application frameworks and they
fit well to the iterative framework development process. Refactoring as a technique plays also
a major part in extreme programming.
12.1.4. Basic Techniques behind Refactoring

How do we introduce high-quality qualities to our software and remove bad smells? One of the
basic procedures of refactoring (besides eliminating duplication) is adding indirection.

Indirection in its most fundamental form mean defining structures (e.g. classes and methods)
and giving them names. Using named structures makes code easy to read because it gives you
a way to explain intention (class and method names) and implementation (class structures and
method bodies) separately. The same technique enables sharing of logic (e.g., methods invoked
in different places or a method in super class shared by all subclasses). Sharing of logic, in turn,
helps you to manage change in systems. Finally, polymorphism (another form of indirection)
provides a flexible, yet clear way to express conditional logic.

242 LOVELY PROFESSIONAL UNIVERSITY