A Law That Helps You Write Loosely Coupled Functions
Tags: programming, javascript, 100daysofcode
Published: 2021-08-01 09:13:42

---
title: "A Law That Helps You Write Loosely Coupled Functions"
published: true
description: "Coupling is the degree of interdependence that exists between software components. Tightly coupled components are harder to maintain, modify and enhance overtime. For this reason, it's good to write loosely coupled functions as much as we can through out the development of a software program."
tags: Programming, Javascript, 100DaysOfCode
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u8zogellxbhwqjav81gl.jpeg
---

There are *programming principles* and there are *frameworks* to help us stick to those principles. One of those frameworks is––**Law of Demeter**.

Coupling is the degree of interdependence that exists between software components. Tightly coupled components are harder to maintain, modify and enhance overtime. For this reason, it's good to write loosely coupled functions as much as we can through out the development of a software program.

>Honour thy functions and thy classes and keep them high up the altar away from undeserving stragers

LoD or **principle of least knowledge** is a design guideline for software development with the notion that a function or similar object should assume as little as possible about the properties and behaviours of components it comes in contact with. It is a novel way of loosely coupling software artifacts to make evolution much easier. It tries to prevent you from reaching into an object to gain access to a third object's methods.

## Breakdown

The law states that any method of an object should call only methods belonging to:

- itself
- any parameters that were passed into the method
- any objects it created
- any directly held component objects

```c++
class Demeter {
    private:
        A *a;
        int func();
    public:
        //...
        void example(B& b);
}

void Demeter::example(B& b) {
    C c;
    int f = func(); // itself

    b.invert(); // any parameters that were passed in to the method

    a = new A();
    a->setActive(); // any objects it created

    c.print(); // any directly held component objects
}
```

## The Worth

Theoretically, it sounds good. But, does it really help in writing more **maintanable** and **adaptable** code. Short answer––Yes. 

Since components are not very knoledgable of each other, you can easily make changes to one without affecting the other.

There have been studies that show C++ classes with large response sets are more prone to error than classes with smaller response sets.

>a **response set** is defined to be the number of functions directly invoked by methods of the class

## Downside

Using the law of demeter will make your code more adaptable and robust, but at a cost: as a "general contractor", your module must delegate and manage any all subcontractors directly, without involving clients of your module. This means that you will be writing a large number of wrapper methods that simply forward the request on to a delegate. These wrapper methods will impose both a runtime cost and a space overhead, which may be significant––even prohibitive––in some applications.

## Helpful Links

- [WikiPedia: Law of Demeter](https://en.wikipedia.org/wiki/Law_of_Demeter)
- [Demystifying the Law of Demeter Principle](https://www.infoworld.com/article/3136224/demystifying-the-law-of-demeter-principle.html)
- [Demeters Law: Dont Talk To Strangers](https://betterprogramming.pub/demeters-law-don-t-talk-to-strangers-87bb4af11694)