law-of-demeter

Enforces Law of Demeter by flagging long dot chains and chained getters in your code.

Updated Sep 9, 2024
One-click install
npx skills add https://github.com/anyulled/my-portfolio-website --skill law-of-demeter-anyulled
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: law-of-demeter
Source: https://github.com/anyulled/my-portfolio-website/tree/main/.agent/skills/law-of-demeter
Command: npx skills add https://github.com/anyulled/my-portfolio-website --skill law-of-demeter-anyulled

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps developers avoid writing fragile, tightly coupled code by enforcing the Law of Demeter, preventing methods from reaching through objects to access other objects' internals.

Core Features & Use Cases

  • Reduces Coupling: Prevents methods from depending on the internal structure of other objects.
  • Improves Maintainability: Makes code more resilient to changes in object structures.
  • Simplifies Testing: Easier to mock and test individual components.
  • Use Case: Refactor long dot chains like user.getProfile().getAddress().getZipCode() into a single method call like user.getZipCode().

Quick Start

Apply the Law of Demeter principle to refactor code that uses long dot chains.

Frequently Asked Questions about law-of-demeter

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

FAQPage Schema
What is the Law of Demeter in software design?

It reduces coupling by enforcing strict rules about object interaction, ensuring methods do not depend on the internal structure of other objects to improve overall code maintainability.

How do I refactor long dot chains like chained getters in my code?

To refactor long dot chains, you replace sequences like `user.getProfile().getAddress().getZipCode()` with a single direct method call such as `user.getZipCode()`, preventing methods from reaching through objects.

Why does tightly coupled code make software hard to maintain?

Tightly coupled code is hard to maintain because changes to an object's internal structure cascade through dependent methods, making the codebase fragile and difficult to modify without introducing regressions.

Does applying the Law of Demeter simplify unit testing?

Applying the Law of Demeter simplifies testing by reducing dependencies on deep object structures, which makes it significantly easier to mock individual components and test them in isolation.

When should I avoid reaching through objects to access internals?

You should avoid reaching through objects whenever a method chains multiple getters, as this creates tight coupling to internal structures and directly violates the Law of Demeter's strict interaction rules.