A design pattern names a recurring arrangement of responsibilities. Start with a behavior that varies, then give it the smallest useful interface. Strategy selects a calculation rule; a factory constructs or selects it; a decorator delegates to an existing rule and adds one behavior. A pattern earns its place when that division makes the contract easier to test.
The SOLID principles become concrete at these boundaries. One collaborator owns one reason to change. New rules can be introduced behind an existing interface. Substitutes preserve shared behavior such as a zero-quantity charge. Read-only consumers don't need write methods, and services can depend on a supplied abstraction. These exercises use plain Java equivalents. They don't start Spring Boot, open a database or pretend that an in-memory lookup is a JPA integration.