Coupling

Software Engineering / 09 Sep 2026 / 8 min read

Reducing Coupling with the Law of Demeter

A small change to one class should not routinely force edits in code that is several objects away. Yet this happens when callers navigate through collaborators to reach deeper objects: order.customer().address().country().code() The line is compact, but the caller now knows that an order exposes a customer, a customer exposes an address, an address exposes a country, and a country exposes a code. If that structure changes, the caller may need to change even when the business question it asks stays the same.

Software Engineering Code Quality

Software Engineering / 08 Sep 2026 / 8 min read

Designing for Change Locality

A product rule changes from “free delivery above $50” to “free delivery above $60.” The code change sounds small, but the developer has to edit a checkout service, an order validator, a receipt formatter, and two unrelated utility modules. Missing one location leaves the system internally inconsistent. The problem is not simply that several files changed. Some changes legitimately cross many files. The warning sign is that one conceptual decision is represented in several places that must change together.

Software Engineering Software Design

Software Engineering / 07 Sep 2026 / 9 min read

Reducing Coupling with Connascence

Two pieces of code are coupled when a change in one can require a change in the other. That definition is useful, but it leaves an important engineering question unanswered: which coupling should you fix first? A shared constant, a parameter order, and a distributed workflow can all create coupling. Treating them as equally harmful leads to unnecessary abstractions in some places and fragile dependencies in others. Connascence gives a more precise mental model. Two software elements are connascent when they must agree in some way for the system to work correctly. By asking what must agree, how difficult that agreement is to maintain, how far apart the elements are, and how many elements participate, you can make better refactoring decisions.

Software Engineering Software Design

Software Engineering / 07 Sep 2026 / 10 min read

Reducing Change Coupling with the Law of Demeter

A line of code can be short and still know too much. Consider a shipping service that needs the destination country for an order: country = order.customer().profile().shippingAddress().countryCode() The line works, but it depends on several structural decisions at once: an order has a customer, the customer has a profile, the profile owns the shipping address, and the address exposes a country code. If any link in that path changes, the shipping service may need to change even though its actual responsibility did not.

Software Engineering Software Design

Software Engineering / 05 Sep 2026 / 8 min read

Reducing Object Graph Coupling with the Law of Demeter

A small change to an object model can cause surprising edits far away from the changed class. A developer moves an address under a customer profile, for example, and code in pricing, notifications, and reporting all breaks because each caller navigates the same chain of objects. The immediate problem looks like missing properties. The deeper problem is that those callers know the shape of an object graph they do not own.

Software Engineering Software Design