open-closed-principle

To add new payment methods without modifying existing code, you extract an interface from the current conditional branches and implement the new variants as separate classes. These classes are then registered or injected so the core logic remains unchanged and avoids regression.

The open-closed principle in software design states that modules should be open for extension but closed for modification. It prevents feature drift and regression by encouraging a strategy or plugin pattern, allowing you to add new variants without altering working core logic.

To refactor branching conditionals into a strategy pattern, you identify existing if/else branches, extract a common interface, and implement each branch as a separate class. You then register or inject these new variants so the core logic can use them without being modified.

You need to apply the open-closed principle during refactoring when you must support new variants, such as export formats or notification channels, without altering current branches. It is used to prevent regression and churn by keeping the core logic intact while safely extending behavior.

The best way to support new export formats without causing regression is to implement a new class that conforms to an existing interface rather than adding an else/if branch. This strategy-based design keeps core logic intact and prevents feature drift during extension.

Adding else/if branches causes feature drift because it forces you to modify working core logic, increasing the risk of regression and churn. The open-closed principle prevents this by encouraging a plugin pattern where new variants are implemented as separate injected classes.