Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Refactoring: Improving the Design of Existing Code / Edition 1

Refactoring: Improving the Design of Existing Code / Edition 1

4.6 9
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

ISBN-10: 0201485672

ISBN-13: 9780201485677

Pub. Date: 07/12/1999

Publisher: Addison-Wesley

As the application of object technology—particularly the Java programming language—has become commonplace, a new problem has emerged to confront the software development community. Significant numbers of poorly designed programs have been created by less-experienced developers, resulting in applications that are inefficient and hard to maintain and extend.


As the application of object technology—particularly the Java programming language—has become commonplace, a new problem has emerged to confront the software development community. Significant numbers of poorly designed programs have been created by less-experienced developers, resulting in applications that are inefficient and hard to maintain and extend. Increasingly, software system professionals are discovering just how difficult it is to work with these inherited, "non-optimal" applications. For several years, expert-level object programmers have employed a growing collection of techniques to improve the structural integrity and performance of such existing software programs. Referred to as "refactoring," these practices have remained in the domain of experts because no attempt has been made to transcribe the lore into a form that all developers could use. . .until now. In Refactoring: Improving the Design of Existing Code, renowned object technology mentor Martin Fowler breaks new ground, demystifying these master practices and demonstrating how software practitioners can realize the significant benefits of this new process.

With proper training a skilled system designer can take a bad design and rework it into well-designed, robust code. In this book, Martin Fowler shows you where opportunities for refactoring typically can be found, and how to go about reworking a bad design into a good one. Each refactoring step is simple—seemingly too simple to be worth doing. Refactoring may involve moving a field from one class to another, or pulling some code out of a method to turn it into its own method, or even pushing somecode up or down a hierarchy. While these individual steps may seem elementary, the cumulative effect of such small changes can radically improve the design. Refactoring is a proven way to prevent software decay.

In addition to discussing the various techniques of refactoring, the author provides a detailed catalog of more than seventy proven refactorings with helpful pointers that teach you when to apply them; step-by-step instructions for applying each refactoring; and an example illustrating how the refactoring works. The illustrative examples are written in Java, but the ideas are applicable to any object-oriented programming language.

Product Details

Publication date:
Addison-Wesley Object Technology Series
Edition description:
New Edition
Sales rank:
Product dimensions:
7.40(w) x 9.40(h) x 1.10(d)

Table of Contents

1. Refactoring, a First Example.
The Starting Point.
The First Step in Refactoring.
Decomposing and Redistributing the Statement Method.
Replacing the Conditional Logic on Price Code with Polymorphism.
Final Thoughts.

2. Principles in Refactoring.
Defining Refactoring.
Why Should You Refactor?
When Should You Refactor?
What Do I Tell My Manager?
Problems with Refactoring.
Refactoring and Design.
Refactoring and Performance.
Where Did Refactoring Come From?

3. Bad Smells in Code.
Duplicated Code.
Long Method.
Large Class.
Long Parameter List.
Divergent Change.
Shotgun Surgery.
Feature Envy.
Data Clumps.
Primitive Obsession.
Switch Statements.
Parallel Inheritance Hierarchies.
Lazy Class.
Speculative Generality.
Temporary Field.
Message Chains.
Middle Man.
Inappropriate Intimacy.
Alternative Classes with Different Interfaces.
Incomplete Library Class.
Data Class.
Refused Bequest.

4. Building Tests.
The Value of Self-testing Code.
The JUnit Testing Framework.
Adding More Tests.

5. Toward a Catalog of Refactorings.
Format of the Refactorings.
Finding References.
How Mature Are These Refactorings?

6. Composing Methods.
Extract Method.
Inline Method.
Inline Temp.
Replace Temp with Query.
Introduce Explaining Variable.
Split Temporary Variable.
Remove Assignments to Parameters.
Replace Method with Method Object.
Substitute Algorithm.

7. Moving Features Between Objects.
Move Method.
Move Field.
Extract Class.
Inline Class.
Hide Delegate.
Remove Middle Man.
Introduce Foreign Method.
Introduce Local Extension.

8. Organizing Data.
Self Encapsulate Field.
Replace Data Value with Object.
Change Value to Reference.
Change Reference to Value.
Replace Array with Object.
Duplicate Observed Data.
Change Unidirectional Association to Bidirectional.
Change Bidirectional Association to Unidirectional.
Replace Magic Number with Symbolic Constant.
Encapsulate Field.
Encapsulate Collection.
Replace Record with Data Class.
Replace Type Code with Class.
Replace Type Code with Subclasses.
Replace Type Code with State/Strategy.
Replace Subclass with Fields.

9. Simplifying Conditional Expressions.
Decompose Conditional.
Consolidate Conditional Expression.
Consolidate Duplicate Conditional Fragments.
Remove Control Flag.
Replace Nested Conditional with Guard Clauses.
Replace Conditional with Polymorphism.
Introduce Null Object.
Introduce Assertion.

10. Making Method Calls Simpler.
Rename Method.
Add Parameter.
Remove Parameter.
Separate Query from Modifier.
Parameterize Method.
Replace Parameter with Explicit Methods.
Preserve Whole Object.
Replace Parameter with Method.
Introduce Parameter Object.
Remove Setting Method.
Hide Method.
Replace Constructor with Factory Method.
Encapsulate Downcast.
Replace Error Code with Exception.
Replace Exception with Test.

11. Dealing with Generalization.
Pull Up Field.
Pull Up Method.
Pull Up Constructor Body.
Push Down Method.
Push Down Field.
Extract Subclass.
Extract Superclass.
Extract Interface.
Collapse Hierarchy.
Form Template Method.
Replace Inheritance with Delegation.
Replace Delegation with Inheritance.

12. Big Refactorings.
Tease Apart Inheritance.
Convert Procedural Design to Objects.
Separate Domain from Presentation.
Extract Hierarchy.

13. Refactoring, Reuse, and Reality.
A Reality Check.
Why Are Developers Reluctant to Refactor Their Programs?
A Reality Check (Revisited).
Resources and References for Refactoring.
Implications Regarding Software Reuse and Technology Transfer.
A Final Note.

14. Refactoring Tools.
Refactoring with a Tool.
Technical Criteria for a Refactoring Tool.
Practical Criteria for a Refactoring Tool.
Wrap Up.

15. Putting It All Together.
List of Soundbites.
List of Refactorings.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews

4.7 out of 5 based on 0 ratings. 9 reviews.
Anonymous More than 1 year ago
Great examples, very well explained.
Anonymous More than 1 year ago
Anonymous More than 1 year ago
Anonymous More than 1 year ago
Anonymous More than 1 year ago
Refactoring is the process of changing the internal structure of a program without changing its outward behavior. If you are writing a program that you only ever intend to run once, then you have no need to refactor. If, however, you plan on maintaining and adapting your program for years to come, then you will need to know how to change it safely without producing a sloppy, fragile, top-heavy mess. The point of this book is to produce clean, bug-free source code that is easy to adapt to the ever-changing requirements of the marketplace. So this book is as much about writing clean code as it is about refactoring. It identifies around seventy refactorings, explains when you would use each one, and provides some simple source code to illustrate each one.
Anonymous More than 1 year ago
Anonymous More than 1 year ago
The book is split into two sections, the process for refactoring code and the library of patterns. The topic is explained through the actual refactoring of sample code. It is an easy read and does a great job addressing the "wrong" approach to refactoring and a step by step process for doing it right. The website contains a more detailed and complex example of refactoring - the missing chapter. Fowler address the issues with the actual code but I would have liked some discussions on database migration issues. The code we needed to refactor was using ORM (Hibernate) and we shied away from a few classes since we wanted to avoid data migrations. Eventually we'll have to tackle the issue and we won't have a guidebook to help make better choices.
Anonymous More than 1 year ago
Guest More than 1 year ago
A little while back I was introduced to a word I had never heard before, Refactoring. I was told to get Martin Fowler's book and read it so I could gain a better understanding of what Refactoring was. Well folks, I would classify this book as a 'Hidden Treasure'. Although it is not a flashy or well known title, I believe its impact can be much deeper and long lasting than many of the mainstream, more popular technology books. The underlying theories that it teaches can be applied for years, even when languages change. There are only a couple of things I would change about this book, which I will mention below. Preface The Preface it brief enough, and gives the definition for the word Refactoring. This is a good thing because right form the start you get the true definition of Refactoring. In short, refactoring is the process of changing code to improve the internal structure, but not changing the external behavior. Chapter 1: Refactoring, a First Example In this chapter Mr. Fowler tries to start by showing a simple Refactoring example. The problem is that the chapter then goes on for 50+ pages. Mr. Fowler explains his reasons for doing this, but I think that a simple example should have been much simpler. Especially when it is in the first chapter of the book. It's not that this isn't a good chapter. I feel it's just too soon in the book. I would have put it at the end. Chapter 2: Principles of Refactoring This is an excellent chapter. The definition of Refactoring is discussed as well as the following questions: Why should you refactor? When should you refactor? What do I tell my manager? This last question may seem funny, but when you read this chapter you will understand why it is in there. This chapter also discusses common problems that occur during Refactoring, and Refactoring and performance. Chapter 3: Bad Smells in Code In this chapter things that cause code to 'smell' are discussed. When code 'smells' it could be an indicator that refactoring is needed. 22 different 'smells' are discussed. My favorites were Duplicated Code, Large Class, and Lazy Class. This is a chapter full of awesome hints. Chapter 4: Building Tests Building tests is an important part refactoring. Refactoring is done in small steps, and after every step you should test. In this chapter the discussion covers the processes and methodology of applying tests during refactoring. Chapter 5: Toward a Catalog of Refactorings This chapter is a quick setup for chapters 6 to 12. Mr. Fowler explains his method for cataloging the individual refactorings. What is pretty amazing is that he has taken a lot of time naming and detailing each refactoring. Chapter 6: Composing Methods One of my favorite chapters. Mr. Fowler opens by saying, "A large part of my refactoring is composing methods to package code properly." This chapter is all about that. 9 total refactorings are explained. My favorite ones are Inline Method and Extract Method. Chapter 7: Moving Features Between Objects Sometimes you need to move things from one object to another. This chapter discusses the art of moving features between objects. 8 total refactorings are discussed and detailed. My favorite from this chapter is Extract Class. Chapter 8: Organizing Data A very large chapter that discusses in meticulous detail 16 refactorings that will make it much easier to work with data. One thing that becomes very obvious in this chapter is that certain refactorings can go either way. What I mean is illustrated by these two: Change Value to Reference and Change Reference to Value. So some refactorings are not just one way deals. It just depends on the situation. Chapter 9: Simplifying Conditional Expressions This is a very useful chapter since conditional logic is a common occurrence in the programming world. Because conditional logic has a tendency to get very complex, this chapter has 8 refact