agentleFS
ch4570ch4570/vulpora/skills/oop-design-review/SKILL.md

oop-design-review

Skill1 starsChanged 56 days agoApache-2.0View on GitHub

Review object responsibilities, cohesion, encapsulation, and collaboration using SOLID and GRASP. Use for object-oriented design review, not implementation scaffolding.

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When turning something into an entity method, make the entity uphold the persistence invariants (identifier/association consistency).

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Object-Oriented Design Review (OOP Design Review)

A skill that diagnoses and improves design smells using the roles, responsibilities, and collaboration and responsibility-driven design of Cho Young-ho's "Object" and "The Reality and Misconception of Object Orientation", together with SOLID, GRASP, and the cohesion/coupling principles. For grounding facts, see this skill's reference/kb/ (SOLID, GRASP, cohesion/coupling, encapsulation/invariants, composition vs. inheritance, the Law of Demeter); for the principles, see reference/principles.md. The index is reference/kb/INDEX.md (if you can't find the path, search with Glob).

Review order (proceed exactly like this)

  1. Diagnose responsibility placement — Is the logic piled up in a service far away from the data (the entity) (anemic domain)?
  2. Tell, Don't Ask — Code that calls getX() and then decides externally and setY()s → delegate to the object that holds that data.
  3. Encapsulation — Is mutable internal state (collections/state) exposed as-is → read-only + mutating methods.
  4. Dependency direction — Does a stable abstraction depend on an unstable concrete (DIP violation) → invert via an interface (port).
  5. Persistence leakage — The domain depends directly on EntityManager/@Repository, the entity is exposed all the way to the API → separate them.
  6. Report — Before/After + application steps. Don't break persistence invariants or transaction semantics (separate out behavior changes).

Design smell → prescription

SmellPrescription
Anemic domain (logic concentrated in the service)Extract+Move into a domain method (order.cancel())
Tell-Don't-Ask violation / message chainDelegate the message to the collaborator, Hide Delegate
Encapsulation violation (mutable exposure)Read-only exposure + mutate via an intention-revealing method
Misplaced responsibility (Feature Envy)Move Function — to the data holder
Concrete dependence (new Impl())Interface (port) + constructor DI (DIP)
Behavior decided by type branchingUse polymorphism (sealed/strategy) — pair with design-pattern-apply

Rules

  • Decide responsibility by "who is the most natural to bear it" (behavior first, not data).
  • When turning something into an entity method, make the entity uphold the persistence invariants (identifier/association consistency).
  • Changing transaction boundaries or association fetching is a behavior impact → separate it from pure refactoring and mark it.

Example (anemic domain → rich domain)

// Before — the service pulls out entity data to decide/assemble (Anemic + Ask)
if (order.getStatus() == OPEN && order.getItems().isNotEmpty()) order.setStatus(CANCELLED)
// After — the entity performs the responsibility with its own invariants (Tell, Don't Ask)
order.cancel()   // validates state/conditions internally

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.