From code-foundations
Evaluates class and routine design against Code Complete rules: LSP inheritance, parameter count limits, cohesion classification, containment-vs-inheritance.
How this skill is triggered — by the user, by Claude, or both
Slash command
/code-foundations:cc-routine-and-class-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Three checks catch design problems that can't be patched post-hoc (they require architectural change, not a fix):
Three checks catch design problems that can't be patched post-hoc (they require architectural change, not a fix):
| Check | What |
|---|---|
| LSP test | Is "A is a B" literally true? If not, the inheritance is wrong |
| Containment default | If LSP feels like purity theater, use containment — it's fixable; inheritance isn't |
| Parameter count | Over 7 parameters predicts interface errors — the interface is wrong |
A passing test suite does not clear these: code can pass all tests on day 1 and still carry VIOLATION-level design debt that surfaces during later modification.
Shared thresholds (parameters 7±2, inheritance depth, routine length, cohesion spectrum): Read(${CLAUDE_PLUGIN_ROOT}/references/cc-foundations.md).
Activity) — but "framework examples use inheritance" is not a mandate.Execute the design checklists against routines and classes: Read(${CLAUDE_SKILL_DIR}/checklists.md). Output one row per item: | Item | Status | Evidence | Location |.
| Severity | Criteria |
|---|---|
| VIOLATION | Fails a checklist item (e.g. 10+ params); breaks LSP/encapsulation (empty override, protected base data) |
| WARNING | Near a limit needing justification (8–9 params, 3-level inheritance); a subjective abstraction concern |
| PASS | Meets or exceeds the requirement |
Produce class interface designs, inheritance/containment decisions, routine signatures, and cohesion classifications.
| Count | Status | Action |
|---|---|---|
| 1–5 | PASS | None |
| 6–7 | PASS | Minor concern; document if unusual |
| 8–9 | WARNING | Justify in review or redesign |
| 10+ | VIOLATION | Redesign — parameter object or split responsibilities |
Count all parameters including defaulted ones; variadic (*args/...) counts as 1. Ordering convention (order implies data flow): input-only first, input-output second, output-only third.
If A inherits from B, every place that uses B can substitute A without breaking. Inheritance requires both:
If either fails, use containment.
FINAL CHECK (after deciding INHERIT, before committing): depth < 3 (definitely < 6)? No empty overrides needed? All base data private (not protected)? If any answer is NO → contain instead.
A routine performs one and only one operation. If you need "and" or "then" to name it, it has multiple operations.
ValidateUserInput(), CalculateTotalPrice(), SendWelcomeEmail().ValidateAndSaveUser(), ReadFileThenParseJSON()."One operation" is at the routine's declared abstraction level: CreateUser() is one operation even though it validates, hashes, and inserts — those are at a lower level.
| Type | Definition | Verdict |
|---|---|---|
| Functional | One and only one operation | ACCEPT |
| Sequential | Operations share data step-to-step in required order | ACCEPT w/caution |
| Communicational | Operations use the same data but are otherwise unrelated | ACCEPT w/caution |
| Temporal | Combined because done at the same time (startup/shutdown) | ACCEPT if it orchestrates calls; FIX if it does the work directly |
| Procedural | Ordered by external requirement (UI flow), not logic | REJECT |
| Logical | A control flag selects one of several unrelated operations | REJECT |
| Coincidental | No discernible relationship | REDESIGN |
"ACCEPT w/caution" = document why this type is acceptable here, review whether functional cohesion is reachable, and add a TODO if it should improve. Caution is permission with accountability, not permission to ignore.
Detecting orchestration (temporal OK): verbs like orchestrates/coordinates/delegates/dispatches/routes suggest orchestration (calls other routines). Verbs like handles/processes/performs/calculates suggest direct work — check the cohesion type and extract the direct work into named routines.
| Type | Steps |
|---|---|
| Sequential | Split per operation; have the dependent routine call what it depends on |
| Communicational | Split into individual routines; reinitialize data near creation; call both from a higher level |
| Temporal | Make the routine an organizer that calls doers; name at the right abstraction level |
| Logical | One routine per distinct operation; move shared code lower; package into a class |
this are fine; class cohesion = "constructs one type of object".await.This is maintenance data, not shipping data: the gap appears during modification, not first commit.
| After | Next |
|---|---|
| Design verified | Skill(code-foundations:cc-defensive-programming) |
npx claudepluginhub ryanthedev/code-foundationsAssigns responsibilities so each class stays focused on one related concern. Use when a class is hard to name, does unrelated work, or a change risks breaking unrelated parts.
SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) for object-oriented design.
Reviews and refactors object-oriented code for SOLID compliance across PHP, Java, Python, TypeScript, and C++. Detects violations, suggests fixes, and explains trade-offs.