# The Law of Demeter - Writing Shy Code

DevFeed: [The Law of Demeter - Writing Shy Code](<https://devfeed.tech/articles/the-law-of-demeter-writing-shy-code-24949.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/06/17/the-law-of-demeter-writing-shy-code/>)

Author: umer

Published: 2016-06-17T00:00:00Z

Content type: tutorial

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [Code](<https://devfeed.tech/topics/code.md>), [modules](<https://devfeed.tech/topics/modules.md>), [Server](<https://devfeed.tech/topics/server.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [maintainability](<https://devfeed.tech/tags/maintainability.md>), [modules](<https://devfeed.tech/tags/modules.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [server](<https://devfeed.tech/tags/server.md>), [structure](<https://devfeed.tech/tags/structure.md>)

## AI overview

The article explains how unmanaged code complexity and excessive coupling between modules can make applications difficult to maintain and refactor. Using a server-side User and Message example, it introduces the Law of Demeter as a guideline for limiting an object's knowledge of and interactions with other objects.

## Source excerpt

In all my years of building server-side applications, I have come to believe that the single most important aspect that determines the long term success of these projects isn't the speed of algorithms or the fancy frameworks. Nope. It's the complexity of the code. Unmanaged complexity has a profound effect on the maintainability of large projects. Applications that are difficult to understand aren't amenable to refactoring. Introducing new features become a slow and painful process, increasing the crucial time to market. I've seen complicated systems where developers were petrified of making even small changes in the fear that they might inadvertently break some other part. Or the spaghetti code that is only understood by a single individual or a handful of developers who get a free pass on anything because the project will be doomed if they quit. There are multiple factors that contribute to code complexity. One important factor is the amount of coupling or interdependencies between the application's modules. Let's walkthrough a trivial example. Suppose there's a server that allows users to connect. When users connect and authenticate, they are wrapped in a 'User' class: // Represents a user class User { public final String username; public final int id; public final Socket socket; public void disconnect() { socket.close(); } // Other methods that operate on the socket. } If we want to send a message a user, we would do something like this: // Another class class Message { // Send "Hello." string to a User public void sayHello(User user) { Socket s = user.socket; // Get the user's socket OutputStream outputStream = s.getOutputStream(); PrintWriter out = new PrintWriter(outputStream); out.println("Hello."); // send the message to the socket. } } The User class has an obvious flaw: it failed to encapsulate the socket object and leaked it to the world. If we want to change this implementation in the future (e.g. use an asynchronous socket library), we'll have to make