Design Patterns in Java: What They Are, When to Use Them, and When Not To
Maya runs a small online bookstore. Her checkout code started simple: add up the cart, apply a discount, print a receipt. Then the business grew. Students asked for 10% off. A seasonal sale added 15%. Loyal customers earned 5%. Each new rule meant opening the checkout code, adding another branch, and re-testing everything the checkout already did — because every edit touched the same method that all the old rules lived in. This is the exact moment design patterns exist for. Not as clever tricks, and not as a badge of seniority — as answers to a recurring question: this part of my program keeps changing; how do I shape the code so the next change is small and safe? This post answers that question with one pattern, worked end to end, and gives you the map for the rest of the track. The principle for this lesson: give what varies a name and a seam. 1. The customer problem Maya's checkout has one job that never changes — turn a cart into a total and a receipt — and one part that ...