Synopses & Reviews
More often than not, developers will stop a large project in the middle of the build stage to rethink and recode the software design so it's cleaner and more efficient. Known as refactoring, this process eats up valuable time and money. To help offset refactoring, this book presents a new process called prefactoring, the premise of which states that you're better off considering the best possible design patterns before you even begin your project.
Prefactoring, in essence, is the art of applying the insights gleaned from previous experience (whether yours or someone else's) when developing software to new projects. Doing so will likely save you from making costly design changes midstream--and maybe even save your job!
This practical, thought-provoking guide details prefactoring guidelines in design, code, and testing, each derived from the lessons of many developers over many years. With these guidelines, you're far more likely to create more readable and maintainable code before you reach the second-guessing stage.
To help communicate the many facets of this process, Prefactoring follows the example of a fictitious client, Sam, as he seeks to create a software system from beginning to implementation. Among the topics covered:
General development issues
Implementation classes
Object-oriented design
Creating reports via separation of concerns
Associations and states
Creating and testing interfaces
If you understand object-oriented design, and you want to save time and money by considering more efficient designs before you begin your project, Prefactoring will show you the way. It won't guarantee that you'll never need to refactor yourdesign or code again, but you're sure to cut down on the amount of refactoring you do.
Synopsis
Developers working on a project will often rethink and recode the software under construction to make its design cleaner and more elegant. Known as "refactoring," this process is done for all sorts of reasons: to facilitate the addition of new features, to improve maintainability, and (or) to increase performance. Refactoring is an important and useful software process.
Refactor enough times though, and you will begin to learn things that you can do when building new software to reduce the amount of refactoring later in the process. Taking these lessons-learned and applying them on subsequent development projects is a process that Ken Pugh refers to as "prefactoring."
This practical, thought-provoking guide details prefactoring guidelines in design, code, and testing, each derived from the lessons of many developers over the years. By following these guidelines, you're far more likely to create more readable and maintainable code than would otherwise be the case.
To help communicate the many facets of this process, Prefactoring follows the development of a software system for a fictitious client, named Sam, from vision to implementation. Some of the guidelines you'll encounter along the way include:
When You're Abstract, Be Abstract All the Way
Splitters Can Be Lumped Easier Than Lumpers Can Be Split
Do a Little Job Well and You May Be Called Upon Often
Plan Globally, Develop Locally
Communicate with Your Code
The Easiest Code to Debug Is That Which is Not Written
Use the Client's Language
Don't Let the Cold Air In
Never Be Silent
Don't Speed Until You Know Where You Are Going
If you have an object-oriented design background, you may save time by considering Ken's prefactoring guidelines before you begin your project, They won't guarantee that you will never need to refactor your design or code again, but you can cut down on the amount of refactoring you do.
Synopsis
Prefactoring approaches software development of new systems using lessons learned from many developers over the years. It is a compendium of ideas gained from retrospectives on what went right and what went wrong in development. Some of these ideas came from experience in refactoring. Refactoring is improving the design of existing code to make it simpler and easier to maintain.
This practical, thought-provoking guide details prefactoring guidelines in design, code, and testing. These guidelines can help you create more readable and maintainable code in your next project.
To help communicate the many facets of this approach, Prefactoring follows the development of a software system for a fictitious client, named Sam, from vision through implementation. Some of the guidelines you'll encounter along the way include:
- When You're Abstract, Be Abstract All the Way
- Splitters Can Be Lumped Easier Than Lumpers Can Be Split
- Do a Little Job Well and You May Be Called Upon Often
- Plan Globally, Develop Locally
- Communicate with Your Code
- The Easiest Code to Debug Is That Which is Not Written
- Use the Client's Language
- Don't Let the Cold Air In
- Never Be Silent
- Don't Speed Until You Know Where You Are Going
About the Author
Ken Pugh has extensive experience in the area of software analysis and design, both as a doer and as a teacher. He's a well-known, frequent conference speaker.
Table of Contents
Copyright; Dedication; Preface; Everybody Is Different; The Design Example; Audience; Contents of This Book; The Cover; Conventions Used in This Book; Using Code Examples; Comments and Questions; Safari Enabled; Acknowledgments; Chapter One: Introduction to Prefactoring; 1.1 What Is Prefactoring?; 1.2 The Three Extremes; 1.3 The Guidelines Explored; 1.4 The Context for This Book; Chapter Two: The System in So Many Words; 2.1 Meet Sam; 2.2 Reinvention Avoidance; 2.3 What's in a Name?; 2.4 Splitters Versus Lumpers; 2.5 Clumping; 2.6 Abstracting; 2.7 Prototypes Are Worth a Thousand Words; Chapter Three: General Development Issues; 3.1 Start with the Big Picture; 3.2 Interface Contracts; 3.3 Validation; 3.4 Code Communicates; 3.5 Consistency Is Simplicity; 3.6 A Prefactoring Attitude; 3.7 Don't Repeat Yourself; 3.8 Documentation of Assumptions and Decisions; 3.9 Dealing with Deviations and Errors; 3.10 Speeding; 3.11 The Spreadsheet Conundrum; 3.12 Tools Are Tools--Use Them Wisely; Chapter Four: Getting the Big Picture; 4.1 The Rest of the Story; 4.2 Process; 4.3 The Initial Design; 4.4 Global Planning, Local Designing; 4.5 Testing Functionality; 4.6 Testing Quality; 4.7 Security; Chapter Five: Got Class?; 5.1 Categories and Classes; 5.2 Declaration Versus Execution; 5.3 Appropriate Inheritance; 5.4 Communicate with Text; 5.5 More Than One; Chapter Six: A Few Words on Classes; 6.1 Honor the Class Maxims; 6.2 Three Laws of Objects; 6.3 Need Determines Class; 6.4 Polymorphism; 6.5 One Little Job; 6.6 Policy Versus Implementation; 6.7 Extreme Naming; 6.8 Overloading Functions; Chapter Seven: Getting There; 7.1 Where We Are; 7.2 Separating Concerns; 7.3 Migrating to the New System; Chapter Eight: The First Release; 8.1 The Proof Is in the Pudding; 8.2 Retrospective Time; 8.3 The System as It Stands Now; 8.4 Operations Interface; 8.5 Abstract Data Types; 8.6 Configuration; 8.7 Testing; 8.8 Dealing with Deviations and Errors; 8.9 A Little Prefactoring; 8.10 The First Released Iteration; 8.11 Sometimes Practice Does Not Match Theory; 8.12 The Rest of the Classes; Chapter Nine: Associations and States; 9.1 Sam's New Requirement; 9.2 Who's in Charge?; 9.3 The State of an Object; Chapter Ten: Interfaces and Adaptation; 10.1 The Catalog Search Use Case; 10.2 Designing the Interface; 10.3 Interface Development; 10.4 Interface Testing; 10.5 Interface Splitting; 10.6 Something Working; Chapter Eleven: Zip Codes and Interfaces; 11.1 Adaptation; 11.2 Pass the Buck; 11.3 Unwritten Code; 11.4 Indirection; 11.5 Logging; 11.6 Paradigm Mismatch; Chapter Twelve: More Reports; 12.1 Fancy Reports; 12.2 Change Happens; 12.3 Exports; Chapter Thirteen: Invoices, Credit Cards, and Discounts; 13.1 The Next Step; 13.2 The Language of the Client; 13.3 Security and Privacy; Chapter Fourteen: Sam Is Expanding; 14.1 The Second Store; 14.2 A New Development; 14.3 The Third Store; 14.4 Goodbye Sam; 14.5 Generality; Chapter Fifteen: A Printserver Example; 15.1 Introduction; 15.2 The System; 15.3 The Message; 15.4 Testing; 15.5 Logging; 15.6 Still More Separation; 15.7 Epilogue; Chapter Sixteen: Antispam Example; 16.1 The Context; 16.2 Spam Checking; 16.3 The ReceivingMailServer; 16.4 ReceivedMailExaminer; 16.5 The Full Flow; Chapter Seventeen: Epilogue; Appendix A: Guidelines and Principles; A.1 Guidelines; A.2 Guidelines in Alphabetical Order; A.3 Software Design Principles; Appendix B: Source Code; B.1 com.samscdrental.configuration Package; B.2 com.samscdrental.controller Package; B.3 com.samscdrental.dataaccess Package; B.4 com.samscdrental.display.adt Package; B.5 com.samscdrental.display Package; B.6 com.samscdrental.failures Package; B.7 com.samscdrental.helper Package; B.8 com.samscdrental.importexport Package; B.9 com.samscdrental.migration Package; B.10 com.samscdrental.model.adt Package; B.11 com.samscdrental.model.dto Package; B.12 com.samscdrental.model Package; B.13 com.samscdrental.reports Package; B.14 com.samscdrental.tests Package; Colophon;