Applying the Observer Pattern to Refactor Order Completion Logic

Recently, while refactoring a transaction system, the author applied the Observer design pattern to the order‑completion process and shares the principle and suitable scenarios.

The business context is an order‑status flow where, after an order is completed, many follow‑up tasks such as notifying users, billing, deducting points, and informing other systems must be performed.

Before the refactor, the OrderMessageResolver class contained a large resolve method that mixed many responsibilities, violating the single‑responsibility principle, making the code hard to read, maintain, and extend.

To solve these problems, the Observer pattern—defining a one‑to‑many dependency where multiple observers listen to a subject—was introduced. The JDK provides built‑in support for this pattern, as shown in the class diagram.

In the new design, the order‑completion status becomes the subject, and each post‑completion action (e.g., billing, point deduction) is an observer. After the order is marked complete, the subject notifies all registered observers.

This refactoring yields a clear structure: the resolver only updates the order status, while observers handle subsequent actions, resulting in loose coupling, better extensibility (new observers can be added without touching existing code), and adherence to the OCP (open for extension, closed for modification).

Finally, the author reflects on code craftsmanship, emphasizing that treating code as an artwork and maintaining “code cleanliness” leads to personal growth and higher quality software.