Object-Oriented Reengineering Patterns

by Serge Demeyer, Stéphane Ducasse, & Oscar Nierstrasz

Read here Read at LibreTextsPDF

This text is a guide on how to reverse engineer legacy systems to understand their problems, and then reengineer those systems to meet new demands. Patterns are used to clarify and explain the process of understanding large code bases, to transform them to meet new requirements. The key insight is that the right design and organization of your system is not something that can be evident from the initial requirements alone, but as a consequence of understanding how these requirements evolve.

Description from LibreTexts.

Subjects
Engineering, Computer Science
Licence
CC BY-SA, as LibreTexts states it
Who can read
Tweens profiles and older, judged from its title and subjects

Contents

LibreTexts writes equations in TeX, and here they show as TeX; the PDF has them typeset.

  1. Front Matter
  2. TitlePage
  3. InfoPage
  4. Foreword
  5. Table of Contents
  6. Licensing
  7. Preface
  8. About the Authors
  9. 1: Reengineering Patterns
  10. 1.1: Why do we Reengineer?
  11. 1.2: The Reengineering Lifecycle
  12. 1.3: Reengineering Patterns
  13. 1.4: The Form of a Reengineering Pattern
  14. 1.5: A Map of Reengineering Patterns
  15. 2: Setting Direction
  16. 2.1: Setting Direction
  17. 2.2: Agree on Maxims
  18. 2.3: Appoint a Navigator
  19. 2.4: Speak to the Round Table
  20. 2.5: Most Valuable First
  21. 2.6: Fix Problems, Not Symptoms
  22. 2.7: If It Ain’t Broke, Don’t Fix It
  23. 2.8: Keep It Simple
  24. 3: First Contact
  25. 3.1: First Contact
  26. 3.2: Chat with the Maintainers
  27. 3.3: Read all the Code in One Hour
  28. 3.4: Skim the Documentation
  29. 3.5: Interview During Demo
  30. 3.6: Do a Mock Installation
  31. 4: Initial Understanding
  32. 4.1: Initial Understanding
  33. 4.2: Analyze the Persistent Data
  34. 4.3: Speculate about Design
  35. 4.4: Study the Exceptional Entities
  36. 5: Detailed Model Capture
  37. 5.1: Detailed Model Capture
  38. 5.2: Tie Code and Questions
  39. 5.3: Refactor to Understand
  40. 5.4: Step Through the Execution
  41. 5.5: Look for the Contracts
  42. 5.6: Learn from the Past
  43. 6: Tests — Your Life Insurance!
  44. 6.1: Tests — Your Life Insurance!
  45. 6.2: Write Tests to Enable Evolution
  46. 6.3: Grow Your Test Base Incrementally
  47. 6.4: Use a Testing Framework
  48. 6.5: Test the Interface, Not the Implementation
  49. 6.6: Record Business Rules as Tests
  50. 6.7: Write Tests to Understand
  51. 7: Migration Strategies
  52. 7.1: Migration Strategies
  53. 7.2: Involve the Users
  54. 7.3: Build Confidence
  55. 7.4: Migrate Systems Incrementally
  56. 7.5: Prototype the Target Solution
  57. 7.6: Always Have a Running Version
  58. 7.7: Regression Test After Every Change
  59. 7.8: Make a Bridge to the New Town
  60. 7.9: Present the Right Interface
  61. 7.10: Distinguish Public from Published Interface
  62. 7.11: Deprecate Obsolete Interfaces
  63. 7.12: Conserve Familiarity
  64. 7.13: Use Profiler Before Optimizing
  65. 8: Detecting Duplicated Code
  66. 8.1: Detecting Duplicated Code
  67. 8.2: Compare Code Mechanically
  68. 8.3: Visualize Code as Dotplots
  69. 9: Redistribute Responsibilities
  70. 9.1: Redistribute Responsibilities
  71. 9.2: Move Behavior Close to Data
  72. 9.3: Eliminate Navigation Code
  73. 9.4: Split Up God Class
  74. 10: Transform Conditionals to Polymorphism
  75. 10.1: Transform Conditionals to Polymorphism
  76. 10.2: Transform Self Type Checks
  77. 10.3: Transform Client Type Checks
  78. 10.4: Factor out State
  79. 10.5: Factor out Strategy
  80. 10.6: Introduce Null Object
  81. 10.7: Transform Conditionals into Registration
  82. 11: Appendix A – Thumbnail Patterns
  83. 11.1: Testing Patterns
  84. 11.2: Refactorings
  85. 11.3: Design Patterns
  86. Back Matter
  87. Index
  88. Bibliography
  89. Index
  90. Glossary
  91. Detailed Licensing