solid-principles

Review and refactor object-oriented TypeScript code against the five SOLID design principles.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Object-oriented codebases accumulate design problems—god classes, switch statements that grow forever, subclasses that break caller expectations, fat interfaces, and hard-coded vendor dependencies—that make code hard to test, extend, and maintain. This Skill diagnoses those problems using the five SOLID principles and guides targeted refactors, while also pushing back on over-engineering when abstractions aren't warranted. ## Core Features & Use Cases - SOLID violation diagnosis: Checklists and code smells for SRP, OCP, LSP, ISP, and DIP, each with plain-language explanations and TypeScript examples. - Deep-dive references: Full before/after TypeScript refactors for each principle, covering real-world scenarios like payment gateways, repositories, and notification channels. - Over-engineering guardrails: An anti-patterns catalogue covering premature interfaces, excessive DI, factory-of-factories, and speculative generality, so fixes don't add needless indirection. - Use Case: When reviewing a service class that directly instantiates a Stripe client, use this Skill to identify the DIP violation, apply the PaymentGateway interface refactor, and make the logic unit-testable with a fake. ## Quick Start Ask the assistant to review this class design for SOLID violations and suggest a refactor.

Frequently Asked Questions about solid-principles

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

FAQPage Schema
How do I check if my class violates the Single Responsibility Principle?

Check whether the class has more than one reason to change tied to different stakeholders. Warning signs include vague names like Manager or Utils, imports from unrelated layers, and methods that don't share the class's fields. Split calculation, persistence, and notification into separate classes.

How to refactor a switch statement to follow the Open/Closed Principle?

Replace the type-based if/else or switch chain with a shared interface and one implementation per variant, such as a Discount interface with PercentageDiscount and FlatAmountDiscount classes. New variants are then added as new classes without editing tested code.

When should I not apply SOLID principles?

Skip SOLID when there is no real variability or seam to protect, such as one-off scripts, single fixed implementations, or throwaway prototypes. Introducing interfaces or DI with only one implementation and no test double is speculative generality that adds indirection without benefit.

What is the difference between an LSP violation and an ISP violation?

An LSP violation means a subtype breaks the base contract, like an override that throws NotSupportedException. An ISP violation means an interface is too fat, forcing implementers to stub unused methods. Splitting the fat interface often fixes both at once.

How do I make business logic testable without a real database or payment API?

Apply the Dependency Inversion Principle: define an interface owned by the domain layer, inject it through the constructor, and pass a fake implementation in tests. This removes the need to mock concrete SDK modules or hit real network services.