Object-Oriented Reengineering Patterns

Serge Demeyer, Stéphane Ducasse, and Oscar Nierstrasz’s Object-Oriented Reengineering Patterns describes how to understand and improve valuable inherited software. This guide follows the version dated November 27, 2013. Ten chapters connect direction-setting, investigation, model capture, testing, migration, duplication, responsibility, and polymorphism. Patterns express recurring problems, forces, and responses; they are decision aids to apply in context rather than mandatory steps for every codebase.

Chapter-by-chapter summaries

Chapter 1: Reengineering Patterns

Legacy software is valuable software whose future work is constrained by its inherited form. Reengineering concerns preserving that value while making needed change possible. Distinguish reverse engineering, which develops understanding, from modification itself. A pattern connects a problem with forces and a response, including consequences. Read the patterns as a related language of choices rather than a list of fashionable improvements to impose without a project goal.

Chapter 2: Setting Direction

Competing interests can pull a reengineering effort toward attractive but low-value work. Direction begins with understanding stakeholders, business needs, and constraints, then selecting changes that matter. Keep the goal visible when new technical discoveries tempt a change in focus. Explain what success would mean to users and maintainers. A technically elegant redesign can still fail if it consumes resources without addressing the reason the project exists.

Chapter 3: First Contact

Initial contact with a system uses people, documents, demonstrations, and code to build a practical starting picture. Different sources can disagree, and none should be assumed complete. Identify who knows which aspects of the system and test claims against observed behavior. The aim is sufficient orientation to choose the next investigation, not exhaustive documentation before learning what is important. Record uncertainty rather than replace it with a confident diagram too early.

Chapter 4: Initial Understanding

The next stage identifies important entities, responsibilities, and relationships. Focused exploration can reveal a useful component or architectural boundary without modeling everything. Compare static structure with how the application is actually used. A name or package boundary may be misleading, so validate the emerging account through examples. The chapter develops a selective understanding guided by the intended reengineering work rather than a detached effort to classify every class.

Chapter 5: Detailed Model Capture

Detailed capture invests more effort in the areas that matter to the project. Tool-supported analysis and close investigation help explain relationships that a first overview cannot establish. Separate observed structure from inferred intention and verify the model against behavior. More detail is useful only when it answers a relevant question or reduces uncertainty. A model that cannot inform a change decision may cost more to maintain than it contributes.

Chapter 6: Tests: Your Life Insurance!

Tests provide evidence about behavior while the implementation changes. A legacy system may lack explicit specifications, making observed behavior and stakeholder knowledge important starting points. Distinguish behavior that must be preserved from a defect the project intends to correct. Build checks around important boundaries and risks instead of assuming that a large test count establishes safety. A test suite supports controlled change, but its omissions remain part of the project’s uncertainty.

Chapter 7: Migration Strategies

Migration concerns how an improved system becomes usable while the old one may still be needed. Incremental transition can expose problems earlier and reduce dependence on a single final switchover. Consider compatibility, data, user experience, and the ability to compare or recover behavior. A migration step should deliver a meaningful, verifiable change. The chapter connects technical sequencing with acceptance and continuity rather than treat deployment as an event after the real work ends.

Chapter 8: Detecting Duplicated Code

Duplication can make a change require several coordinated edits and create opportunities for inconsistent behavior. Detection begins with identifying similar code, but similarity alone does not determine the right abstraction. Examine whether the copies represent the same responsibility and are likely to evolve together. A premature generalization can create a different maintenance problem. Use evidence about change and behavior to decide which duplication should be removed and what interface should replace it.

Chapter 9: Redistribute Responsibilities

A system may contain objects that mainly hold data while a few large components make most decisions. Reengineering can move behavior toward the objects responsible for the relevant information and rules. Determine who should own a decision before moving methods mechanically. Preserve observable behavior through small changes and checks. The goal is understandable collaboration and reduced change coupling, not simply making every class the same size or distributing lines evenly.

Chapter 10: Transform Conditionals to Polymorphism

Repeated type-based conditionals may indicate behavior that belongs in different implementations behind a shared protocol. Polymorphism can make extension more local when the abstraction reflects real variation. The text also makes clear that conditionals are not inherently wrong. Identify the repeated decision and explain how the proposed hierarchy or collaboration changes future modifications. Verify that the transformation preserves behavior and does not introduce an unnecessary abstraction for a stable, simple distinction.

Appendix: Thumbnail Patterns

The appendix brings in related testing, design, and organizational ideas referenced by the main patterns. Use it to understand a dependency or alternative when applying a chapter’s approach. A pattern’s value lies in how it addresses the present forces, so examine its consequences and interactions. Finish with a project narrative showing what was learned, which changes followed, and how evidence established that valuable behavior remained available.

Study instructions

1. Choose a small inherited system and state the user or maintenance problem before proposing changes.
2. Maintain separate records for observed behavior, structural facts, and hypotheses.
3. Investigate selectively and use each discovery to decide the next question.
4. Establish focused behavioral checks before changes that could affect important functions.
5. Plan incremental migration and explain how each step will be verified.
6. Write a final pattern application with the problem, forces, response, evidence, and remaining tradeoffs.

Questions for reflection

• Which part of the legacy system’s value must survive the change?
• When does similar code justify a shared abstraction?
• How would you know that a cleaner design actually improved the original problem?

Sources and coverage

This original study guide follows the complete linked source edition and all of its substantive chapters or named teaching sections. It condenses their main ideas and relationships; the study tasks are guidance for reading alongside the complete resource. It does not reproduce the source exercises or answer key. Book source; Complete source PDF.