design-patterns

Applies Gang-of-Four design patterns to TypeScript code with reference implementations and overuse guidance.

Updated Sep 14, 2026
One-click install
npx skills add https://github.com/Royrahav/my_claude_components --skill design-patterns-royrahav
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-patterns
Source: https://github.com/Royrahav/my_claude_components/tree/main/skills/design-patterns
Command: npx skills add https://github.com/Royrahav/my_claude_components --skill design-patterns-royrahav

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Choosing and correctly implementing a design pattern is error-prone from memory alone: commonly confused pairs like Strategy/State or Decorator/Proxy share nearly identical structure but solve different problems, and patterns are frequently applied prematurely, adding indirection the code never needed. This Skill provides a vetted catalog of the 22 classic Gang-of-Four patterns with symptom-based lookup so the right pattern is matched to an actual, present-tense problem. ## Core Features & Use Cases - Symptom-based pattern lookup: Three tables (Creational, Structural, Behavioral) map concrete code symptoms like "telescoping constructor" or "state-checking conditionals duplicated across methods" to the matching pattern. - Detailed reference files: Each pattern has a dedicated reference with intent, problem, solution, structure, a TypeScript code example, applicability signals, and explicit "when NOT to use" pitfalls. - Confusion-pair disambiguation: Relations sections explicitly distinguish commonly mixed-up patterns (Strategy vs State, Decorator vs Proxy, Adapter vs Bridge, Facade vs Mediator). - Use Case: When refactoring a checkout flow where an Order object's behavior branches on its status everywhere, the symptom table points to the State pattern, and its reference file provides the structure, example, and transition pitfalls before any code is written. ## Quick Start Ask the assistant to apply a design pattern to your code, for example: "Refactor this class using the Strategy pattern" or "What pattern fits this problem?"

Frequently Asked Questions about design-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose the right design pattern for a refactoring problem?

Start from the concrete symptom in your code, not from a desire to use a pattern. Match symptoms like "many optional constructor parameters" or "behavior varies by state" against the catalog's use-when tables, then read the full pattern reference before implementing.

What is the difference between the Strategy and State patterns?

Both delegate behavior to a swappable object via composition, but Strategy objects are independent and unaware of each other, while State objects know about other states and can transition the context between them. Strategy swaps algorithms; State models a lifecycle.

When should I not use a design pattern?

Avoid patterns when the flexibility they provide is not actually needed: a single implementation does not justify Strategy or Factory Method, two or three simple states do not justify State classes, and editable classes do not need Adapter or Decorator wrappers.

What is the difference between Decorator and Proxy?

Both wrap an object behind the same interface, but Decorator adds behavior and is composed by the client, while Proxy controls access or lifecycle of the wrapped object, such as lazy initialization, caching, or access checks.

Is the Singleton pattern recommended in TypeScript?

Singleton is widely overused and complicates testing through hidden global state. In Node.js, a module-level exported instance or constructor-injected dependency usually provides the same single-instance guarantee with less coupling.