Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

oop-principles-solid

Étoiles4

Forks0

Mis à jour26 juin 2026 à 09:05

SOLID principles for reducing coupling and improving testability — SRP, OCP, LSP, ISP, and DIP with annotated examples. TRIGGER when: user mentions SOLID, SRP, OCP, LSP, ISP, DIP, single responsibility principle, open-closed principle, Liskov substitution, interface segregation, dependency inversion, god class, fat interface, one reason to change, extend without modifying, depend on abstractions, interface too large, reduce coupling, improve testability.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

bsene

bsene/skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

Explorateur de fichiers

3 fichiers

SKILL.md

readonly

name	oop-principles-solid
description	SOLID principles for reducing coupling and improving testability — SRP, OCP, LSP, ISP, and DIP with annotated examples. TRIGGER when: user mentions SOLID, SRP, OCP, LSP, ISP, DIP, single responsibility principle, open-closed principle, Liskov substitution, interface segregation, dependency inversion, god class, fat interface, one reason to change, extend without modifying, depend on abstractions, interface too large, reduce coupling, improve testability.
user-invocable	false

SOLID Principles

Quick Reference

Principle	Rule	Signal it's violated	Fix
SRP — Single Responsibility	One reason to change	Class handles auth, hashing, and persistence	Split `UserController` → `UserValidator`, `PasswordHasher`, `UserRepository`
OCP — Open–Closed	Extend via subclass; don't modify proven code	Adding CSV export requires editing `JsonFormatter`	Add `CsvResponseFormatter extends JsonResponseFormatter` without touching the base
LSP — Liskov Substitution	Subtypes substitutable without surprising callers	`instanceof` checks in calling code; subclass throws "not supported"	Split `ReadableCache` / `WritableCache` interfaces instead of `ReadOnlyCache extends Cache`
ISP — Interface Segregation	Many focused interfaces over one fat one	Read-only client forced to implement write methods	Slice fat interface; don't force read-only clients onto write methods
DIP — Dependency Inversion	Depend on abstractions, not concretions	`EmailService` directly instantiates `SendgridClient`	Inject `EmailService(transport: MailTransport)`, not `new SendgridClient()`

→ Full annotated examples for all five principles: references/solid.md

Benchmark

Scenario: .benchmarks/scenarios/solid-001-god-class.md · Run: 2026-06-26

Model	Without	With	Delta
claude-opus-4-8	100%	100%	+0%
claude-sonnet-4-6	100%	100%	+0%
claude-haiku-4-5	100%	100%	+0%

NEUTRAL (no regression). On the OrderService god-class all baselines already name the SRP/DIP violations, split by genuine responsibility, and — notably — do not over-split into anemic classes. The skill neither helps nor harms at this difficulty; the feared dogmatic-over-split regression did not materialise. Follow-up: author a harder borderline scenario (a class that only looks multi-purpose) to find where the skill is load-bearing. Gate per skill-optimizer/release-gates.md.

Plus depuis ce dépôt

même dépôt

simple

bsene/skills

Use this skill whenever writing new code, proposing a bugfix, reviewing a PR/diff, or discussing whether to add an abstraction, config layer, plugin system, or generic mechanism. Also trigger for architecture/design discussions, is this too complex" questions, or any point where Claude is about to suggest introducing a new abstraction layer. The core stance — code is written for humans to read, not as an artwork to admire — optimize for affordance (like a road sign, instantly readable) rather than elegance or cleverness. Trigger even if the user doesn't name "simplicity" explicitly — e.g. "should I make this configurable", "quick fix for this bug", "review this PR", "should I abstract this into a helper", "this codebase feels messy".

2026-07-264

typescript

bsene/skills

TypeScript-specific best-practices and rule enforcement — type safety, runtime validation, error handling, and TS-only conventions. Routes to type-system and Zod sub-skills, the `javascript` skill for JS-foundation rules, and `oop-principles` for design patterns and SOLID. TRIGGER when: language (TypeScript, TS, .ts, .tsx, idiomatic TypeScript), type-system (discriminated unions, generics, utility types, make illegal states unrepresentable, type narrowing), safety (strict mode, any vs unknown, ts-expect-error, ts-ignore, type assertions), runtime (Zod, schema validation, runtime type checks, parse/safeParse), errors (error handling without throwing, union return errors, Result type), ts-conventions (readonly modifier, return type annotations, interface prefix, `as const`), contracts (domain vs DTO, monorepo types, API contract types). DO NOT USE when: user asks generic JS questions with no TS angle — use `javascript` instead.

2026-07-264

typescript-type-system

bsene/skills

Deep dive into TypeScript's type system — narrowing, discriminated unions, mapped types, conditional types, type guards, branding, and escape hatches. TRIGGER when: user asks about unknown vs any, type narrowing, discriminated unions, exhaustiveness checking, mapped types, conditional types, infer keyword, user-defined type guards, type branding, companion object pattern, as const, escape hatches, type assertion, how do I narrow a type, how do I write a type predicate, how to create nominal types, how to prevent structural aliasing, make illegal states unrepresentable, illegal states, state machine types, entity lifecycle types, optional field anti-pattern, discriminated union state modeling, interface vs type alias, when to use interface vs type, enum best practices, typescript enum, const enum, readonly property, ReadonlyArray, lazy object initialization, barrel exports, when to use generics, generic naming conventions, no interface prefix. DO NOT USE when: runtime/schema validation at boundaries (parsing e

2026-07-264

typescript-zod

bsene/skills

Zod v4 best practices — schema design, error handling, transforms, coercion, branded types, and boundary validation. TRIGGER when: user mentions zod, zod validation, zod schema, zod v4, zod parse, zod transform, zod coerce, zod branded types, zod error handling, runtime validation, validate API response, schema composition, zod object, zod mini, zod infer, zod v3 to v4, migrate from zod v3, upgrade zod, zod breaking changes. DO NOT USE when: the question is pure compile-time typing with no runtime validation (discriminated unions, generics, narrowing, `as const`) → use `typescript-type-system`.

2026-07-264

git-hero-git-guru

bsene/skills

Expert Git assistant that answers questions about Git concepts, commands, workflows, and best practices — both in French and English. Use this skill whenever the user mentions Git, version control, commits, branches, merges, rebases, conflicts, stash, push/pull, remotes, history rewriting, or anything related to source code versioning. Also trigger when users say things like 'comment faire un rebase', 'I messed up my history', 'explain branching strategies', 'how do I undo a commit', 'what is the difference between merge and rebase', 'git tips', 'commit message best practices', or any git-related question — even phrased casually or in French. DO NOT USE when: choosing a commit-message emoji → use git-hero-gitmoji; designing/optimizing GitLab CI pipelines → use git-hero-gitlab-dag; non-Git version control (SVN, Mercurial, Perforce).

2026-07-264

git-hero

bsene/skills

Git best practices — commit discipline, branching/history hygiene, safety, and CI/CD pipelines. Routes to `git-guru` (expert Q&A), `gitmoji`, and `gitlab-dag` sub-skills. TRIGGER when: commits (Conventional Commits, atomic commits, commit message format, commit hygiene), history (branch naming, rebase vs merge, clean git history, interactive rebase, history management), safety (force push safety, recover lost commits, reflog, reset), CI/CD (GitLab CI, pipeline optimization, DAG, .gitlab-ci.yml), emoji (gitmoji, commit emoji, "quel emoji pour ce commit"), setup (git configuration, "bonnes pratiques git", "comment faire un rebase", "configure git properly"). DO NOT USE when: user needs a single one-shot git command answer — let Claude answer directly.

2026-07-264

name	oop-principles-solid
description	SOLID principles for reducing coupling and improving testability — SRP, OCP, LSP, ISP, and DIP with annotated examples. TRIGGER when: user mentions SOLID, SRP, OCP, LSP, ISP, DIP, single responsibility principle, open-closed principle, Liskov substitution, interface segregation, dependency inversion, god class, fat interface, one reason to change, extend without modifying, depend on abstractions, interface too large, reduce coupling, improve testability.
user-invocable	false

SOLID Principles

Quick Reference

Principle	Rule	Signal it's violated	Fix
SRP — Single Responsibility	One reason to change	Class handles auth, hashing, and persistence	Split `UserController` → `UserValidator`, `PasswordHasher`, `UserRepository`
OCP — Open–Closed	Extend via subclass; don't modify proven code	Adding CSV export requires editing `JsonFormatter`	Add `CsvResponseFormatter extends JsonResponseFormatter` without touching the base
LSP — Liskov Substitution	Subtypes substitutable without surprising callers	`instanceof` checks in calling code; subclass throws "not supported"	Split `ReadableCache` / `WritableCache` interfaces instead of `ReadOnlyCache extends Cache`
ISP — Interface Segregation	Many focused interfaces over one fat one	Read-only client forced to implement write methods	Slice fat interface; don't force read-only clients onto write methods
DIP — Dependency Inversion	Depend on abstractions, not concretions	`EmailService` directly instantiates `SendgridClient`	Inject `EmailService(transport: MailTransport)`, not `new SendgridClient()`

→ Full annotated examples for all five principles: references/solid.md

Benchmark

Scenario: .benchmarks/scenarios/solid-001-god-class.md · Run: 2026-06-26

Model	Without	With	Delta
claude-opus-4-8	100%	100%	+0%
claude-sonnet-4-6	100%	100%	+0%
claude-haiku-4-5	100%	100%	+0%

NEUTRAL (no regression). On the OrderService god-class all baselines already name the SRP/DIP violations, split by genuine responsibility, and — notably — do not over-split into anemic classes. The skill neither helps nor harms at this difficulty; the feared dogmatic-over-split regression did not materialise. Follow-up: author a harder borderline scenario (a class that only looks multi-purpose) to find where the skill is load-bearing. Gate per skill-optimizer/release-gates.md.