arch-solid

One-line summary

The five principles that shape healthy object-oriented and component design — applied with judgment, not dogma. Each principle has a specific motivation and a corresponding overuse anti-pattern.

When to use this skill

• Code review where structure / responsibility / coupling is the concern.
• Component design discussion: should this be one class or two; should this interface be split.
• Onboarding: explaining the underlying principles that motivate many GoF patterns.
• Architecture discussions where the dependency direction matters (DIP underpins hexagonal architecture).

When NOT to use this skill

• Tactical fixes for individual smells → the per-pattern skills (gof-*, ddd-anti-patterns) are more concrete.
• Dogmatic application as a checklist ("does this violate any SOLID principle?") — that's how SOLID becomes anti-pattern. Each principle is a direction, not a binary.

Core content

S — Single Responsibility Principle. "A class should have one reason to change." Uncle Bob's gloss: "responsibility = reason to change", not "responsibility = task". The principle is about the change axis — different stakeholders should not need to modify the same class for unrelated reasons. Overapplied: one class per method, files everywhere, indirection without benefit.