Object-Oriented Reengineering Patterns

Object-OrientedReengineering PatternsSerge DemeyerStéphane DucasseOscar NierstraszVersion of 2013-11-27

ii

iiiPraise for Object-Oriented Reengineering Patterns“How” to refactor is already well covered in the literature. However,“When” and “Why” can only be learned by experience. This book willgive you a head start in learning when to start redesigning a system, whento stop for now, and what effects you can expect to see from your efforts.— Kent Beck, Director, Three Rivers InstituteThis book is full of practical, hands-on reengineering knowledge and expertise presented in a form that makes it easy to understand and use. Thepatterns in this book thus help everyone who is concerned with usingreengineering to guide their work. I wish I had had this book in my library earlier.— Frank Buschmann, Senior Principal Engineer Siemens AGThis book is more than its title advertises. Effective reengineering is reallyabout purposeful and efficient reading of someone else’s code in order toproduce predictable change. The same processes the authors highlight aspatterns of skillful reengineering behavior can easily be cast as the skillsyou need to create readable, maintainable software systems.— Adele Goldberg, Neometron, Inc.If a guy named Dave brought a large box to my office that contained alot of documentation and two CDs-installation disks for software that mycompany wanted to reengineer — I’d be happy to have the authors of thisbook by my side. Barring that, having their book is the next best thing. Nosilver bullets, no hype, no promises that this will be easy — just a down-toearth, easy-to-read, extremely useful book of helpful guidelines to tacklethe project. Buy this book and browse it before Dave arrives in your office!It just might save you and your company a lot of grief.— Linda Rising, Independent Consultant

ivThis book is available as a free download from http://scg.unibe.ch/oorp/.Copyright 2003 by Elsevier Science (USA).Copyright 2008, 2009 by Serge Demeyer, Stéphane Ducasse and Oscar Nierstrasz.The contents of this book are protected under Creative Commons Attribution-ShareAlike 3.0Unported license.You are free:to Share — to copy, distribute and transmit the workto Remix — to adapt the workUnder the following conditions:Attribution. You must attribute the work in the manner specified by the author or licensor(but not in any way that suggests that they endorse you or your use of the work).Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. For any reuse or distribution, you must make clear to others the license terms of thiswork. The best way to do this is with a link to this web page: http://creativecommons.org/licenses/by-sa/3.0/ Any of the above conditions can be waived if you get permission from the copyrightholder. Nothing in this license impairs or restricts the author’s moral rights.Your fair dealing and other rights are in no way affected by the above. Thisis a human-readable summary of the Legal Code (the full /3.0/legalcodePublished by Square Bracket Associates, Switzerland. SquareBracketAssociates.orgISBN 978-3-9523341-2-6First Open-Source Edition, June, 2008. Revised, September, 2009.

vFor Ann, Sara and Niels.For Florence, Quentin, Thibaut and Camille.For Angela and Frida.

vi

ForewordForeword by Martin FowlerFor a long time it’s puzzled me that most books on software developmentprocesses talk about what to do when you are starting from a blank sheetof editor screen. It’s puzzled me because that’s not the most common situation that people write code in. Most people have to make changes to anexisting code base, even if it’s their own. In an ideal world this code baseis well designed and well factored, but we all know how often the idealworld appears in our career.So this book is important because it’s written from the perspective ofwhat to do with an imperfect yet valuable code base. I also like the fact thatit’s based on an effective mix of academic and industrial work. I visitedthe FAMOOS group in their early days during a chill early winter in Bern.I liked the way that they cycled between the field and the lab, trying outideas on real projects, coming back to the lab to reflect.This resulting book speaks with that experience. It gives you the building blocks for a plan to tackle a difficult code base, it gives you context fortechniques like refactoring. It is a sad fact that there are too few of thesekinds of books out there, when reengineering is still a common event. ButI’m at least glad to see that while there aren’t many books in this vein, thisbook is an example of how good they are.Martin Fowler, Thought Works, Inc.vii

viiiFOREWORDForeword by Ralph E. JohnsonOne of the signs of a good pattern is that experts who read it are likely tosay “of course, everybody knows that” but beginners are likely to say “interesting, but will it work?” Patterns should be easy to follow, but the mostvaluable patterns are those that are not obvious. Experts have learnedfrom experience that the patterns work, but beginners have to take thepatterns on faith until they use them and develop their own experience.Over the last couple of years, I’ve had the chance to give the patternsin this book to a wide variety of people and discuss them. My pattern discussion group has a few members who have decades of consulting experience, and they could quickly regale the group with stories of using thesepatterns. The younger members loved the stories as they were convincedof the value of the patterns.I made students in my software engineering class read some of thepatterns as part of a section on reengineering. The section went well eventhough none of the students got excited by the patterns. They didn’t havethe experience to evaluate them. However, one of the students came backto me after his summer job and said that of everything in the course, thematerial that was the most useful was the patterns on reverse engineering.Before that experience, the patterns seemed believable. Afterwards, theywere believed!If you have a lot of experience with software reengineering then youprobably won’t learn much from this book. You should read it anyway,because you’ll want to give copies to people you work with, and you willwant to use the vocabulary of the book when you talk with them. If youare new to reengineering, you should read the book, learn the patterns,and try them. You will learn a lot that will be valuable. Don’t expect tounderstand the patterns completely before you try them, because patternsare practical, and practical knowledge has to be experienced to be fully understood. Nevertheless, the book will give you a big advantage. It is mucheasier to learn when you have a path to follow, and this book provides areliable guide.Ralph E. Johnson, University of Illinois at Urbana-Champaign

ineering Patterns31.1Why do we Reengineer? . . . . . . . . . . . . . . . . . . . . .31.2The Reengineering Lifecycle . . . . . . . . . . . . . . . . . . .81.3Reengineering Patterns . . . . . . . . . . . . . . . . . . . . . .121.4The Form of a Reengineering Pattern . . . . . . . . . . . . . .141.5A Map of Reengineering Patterns . . . . . . . . . . . . . . . .14II2Reverse Engineering17Setting Direction192.1Agree on Maxims . . . . . . . . . . . . . . . . . . . . . . . . .232.2Appoint a Navigator . . . . . . . . . . . . . . . . . . . . . . .252.3Speak to the Round Table . . . . . . . . . . . . . . . . . . . .272.4Most Valuable First . . . . . . . . . . . . . . . . . . . . . . . .292.5Fix Problems, Not Symptoms . . . . . . . . . . . . . . . . . .332.6If It Ain’t Broke, Don’t Fix It . . . . . . . . . . . . . . . . . . .352.7Keep It Simple . . . . . . . . . . . . . . . . . . . . . . . . . . .37ix

x345III67CONTENTSFirst Contact393.1Chat with the Maintainers . . . . . . . . . . . . . . . . . . . .453.2Read all the Code in One Hour . . . . . . . . . . . . . . . . .533.3Skim the Documentation . . . . . . . . . . . . . . . . . . . . .613.4Interview During Demo . . . . . . . . . . . . . . . . . . . . .693.5Do a Mock Installation . . . . . . . . . . . . . . . . . . . . . .77Initial Understanding834.1Analyze the Persistent Data . . . . . . . . . . . . . . . . . . .874.2Speculate about Design . . . . . . . . . . . . . . . . . . . . . .974.3Study the Exceptional Entities . . . . . . . . . . . . . . . . . . 107Detailed Model Capture1175.1Tie Code and Questions . . . . . . . . . . . . . . . . . . . . . 1215.2Refactor to Understand . . . . . . . . . . . . . . . . . . . . . . 1275.3Step Through the Execution . . . . . . . . . . . . . . . . . . . 1335.4Look for the Contracts . . . . . . . . . . . . . . . . . . . . . . 1375.5Learn from the Past . . . . . . . . . . . . . . . . . . . . . . . . 141ReengineeringTests: Your Life Insurance!1471496.1Write Tests to Enable Evolution . . . . . . . . . . . . . . . . . 1536.2Grow Your Test Base Incrementally . . . . . . . . . . . . . . . 1596.3Use a Testing Framework . . . . . . . . . . . . . . . . . . . . 1636.4Test the Interface, Not the Implementation . . . . . . . . . . 1716.5Record Business Rules as Tests . . . . . . . . . . . . . . . . . 1756.6Write Tests to Understand . . . . . . . . . . . . . . . . . . . . 179Migration Strategies1817.1Involve the Users . . . . . . . . . . . . . . . . . . . . . . . . . 1857.2Build Confidence . . . . . . . . . . . . . . . . . . . . . . . . . 1897.3Migrate Systems Incrementally . . . . . . . . . . . . . . . . . 191

CONTENTSxi7.4Prototype the Target Solution . . . . . . . . . . . . . . . . . . 1957.5Always Have a Running Version . . . . . . . . . . . . . . . . 1997.6Regression Test After Every Change . . . . . . . . . . . . . . 2017.7Make a Bridge to the New Town . . . . . . . . . . . . . . . . 2037.8Present the Right Interface . . . . . . . . . . . . . . . . . . . . 2077.9Distinguish Public from Published Interface . . . . . . . . . . 2117.10 Deprecate Obsolete Interfaces . . . . . . . . . . . . . . . . . . 2157.11 Conserve Familiarity . . . . . . . . . . . . . . . . . . . . . . . 2197.12 Use Profiler Before Optimizing . . . . . . . . . . . . . . . . . 22189Detecting Duplicated Code2238.1Compare Code Mechanically . . . . . . . . . . . . . . . . . . 2278.2Visualize Code as Dotplots . . . . . . . . . . . . . . . . . . . . 233Redistribute Responsibilities2399.1Move Behavior Close to Data . . . . . . . . . . . . . . . . . . 2439.2Eliminate Navigation Code . . . . . . . . . . . . . . . . . . . 2539.3Split Up God Class . . . . . . . . . . . . . . . . . . . . . . . . 26310 Transform Conditionals to Polymorphism26910.1 Transform Self Type Checks . . . . . . . . . . . . . . . . . . . 27310.2 Transform Client Type Checks . . . . . . . . . . . . . . . . . . 28110.3 Factor out State . . . . . . . . . . . . . . . . . . . . . . . . . . 29110.4 Factor out Strategy . . . . . . . . . . . . . . . . . . . . . . . . 29510.5 Introduce Null Object . . . . . . . . . . . . . . . . . . . . . . . 29910.6 Transform Conditionals into Registration . . . . . . . . . . . 303IVAppendicesA Thumbnail patterns313315A.1 Testing Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 316A.1.1 Retest Persistent Problems . . . . . . . . . . . . . . . . 316A.1.2 Test Fuzzy Features . . . . . . . . . . . . . . . . . . . . 316