design-patterns

Goal: use patterns to clarify design, not to decorate simple code. Use for: - recurring design problems with known solutions - naming and structuring a chosen approach - reviewing whether a pattern fits or adds noise Workflow: 1. State the actual problem and forces involved. 2. Match it to a pattern's intent, not its name. 3. Apply the smallest form that solves the problem. 4. Name the participants clearly in the code. 5. Reassess: would plain code be simpler here. 6. Verify behavior is unchanged and clearer. Common patterns: - strategy for interchangeable behavior - factory for controlled construction - adapter to bridge incompatible interfaces - observer for event notification - decorator to add behavior without subclassing Rules: - choose by intent, not by familiarity - do not introduce a pattern for a one-off case - prefer composition over inheritance-heavy patterns - the simplest design that works beats a clever one