Well in the real world you would have all the coupon codes, amounts, and any other special behavior driven by entries in a database. It would never be in code.

Well in the real world you would have all the coupon codes, amounts, and any other special behavior driven by entries in a database. It would never be in code. So the code would either be checking the database on every call, or loading the current valid coupons into some kind of resident app memory (and keeping them up-to-date somehow), depending on the platform. So I'm not going to think about how different coupon codes would change the code complexity until I see what a real-world implementation with database-driven coupon codes looks like. Testing is a whole other animal. It could be that a DiscountService interface works best from a testing perspective. But within the scope of the post, a DiscountService interface with different implementations for Shipping and Retail Price certainly isn't less complex than the original code.