Object-Oriented Programming and Design Questions

When to prefer Strategy over Factory (manager perspective)

Prefer Strategy when you need to vary behavior (algorithms, rules) at runtime, keep class responsibilities small, and let teams add new behaviors without touching shared control flow. Use Factory when the main concern is instantiation or selecting concrete types based on configuration.

Concrete example — Checkout promotion engine

Problem: multiple promotion rules (percentage, fixed discount, BOGO, customer-segment) produced a growing if/else or switch in CheckoutService.

Strategy approach:

• Define PromotionStrategy interface with apply(cart): CartResult.
• Implement PercentageStrategy, BogoStrategy, VIPStrategy.
• Inject a list of active strategies (ordered) via DI; CheckoutService iterates and applies each.
  Benefits: removes conditionals, isolates rules so different teams own strategies, easier rollout/feature flags.

Testing strategy

• Unit tests per strategy: deterministic inputs → expected cart outcomes (edge cases: zero quantity, stacking rules).
• Integration test for CheckoutService with a small set of strategies (use fakes or real implementations).
• Property tests for idempotence/commutativity where relevant.
• Contract tests ensuring each strategy conforms to apply() contract; mutation tests to ensure conditionals don’t regress.

Manager-level considerations

• Ownership: assign each strategy to a feature team.
• Review: enforce small surface area and clear telemetry.
• Deployment: use feature flags to enable strategies gradually.