The Law of Demeter Principle, also known as the Principle of Least Knowledge, is a fundamental software development concept that encourages the creation of systems with low coupling and high cohesion. The goal is to make code easier to understand, maintain, and modify by limiting communication between objects.
Originally formulated by Ian Holland in 1987, during his master’s thesis at Northeastern University, this principle gained popularity in the 1990s when it was popularized by Karl Lieberherr and other researchers in the software engineering field.
The principle states that an object should only know its immediate neighbors and should not have knowledge of more distant objects. In other words, an object should not interact with objects that are not part of its immediate “neighborhood.”
For example, imagine we have a class called Shop
that contains a method called place_order
to create an order for a specific product. Instead of allowing the Shop
class to directly access the Product
class, the principle suggests that the Shop
class should only send a message to the Order
class, which in turn accesses the Product
class. This means that the Shop
class does not need to know anything about the Product
class, other than the fact that an order needs to be created for that product.
Here’s how this might look in Python:
class Product:
def __init__(self, name, price):
self.name = name
self.price = price
class Order:
def __init__(self, product, quantity):
self.product = product
self.quantity = quantity
def get_total_price(self):
return self.product.price * self.quantity
class Shop:
def __init__(self):
self.orders = []
def place_order(self, product, quantity):
order = Order(product, quantity)
self.orders.append(order)
def get_total_sales(self):
total = 0
for order in self.orders:
total += order.get_total_price()
return total
shop = Shop()
product1 = Product("Laptop", 1500)
product2 = Product("Smartphone", 800)
shop.place_order(product1, 2)
shop.place_order(product2, 3)
print(f"Total Sales: ${shop.get_total_sales()}")
In this example, the Shop
class interacts only with the Order
class and does not directly interact with the Product
class. This adheres to the Law of Demeter, as each class only knows about its immediate neighbors.
Correct implementation of this principle leads to a more modular and easy-to-understand software structure. Each object is responsible for its own functionality and does not need to know the internal complexity of other objects. This also makes the software easier to maintain and modify since changes made to one object do not directly affect other objects.
However, applying the Law of Demeter can also have disadvantages. In some cases, it may be necessary to access more distant objects to perform a particular task, which can lead to more complex code and a higher processing load. Therefore, it is important to balance the benefits of this principle with the specific needs of each use case.
In summary, the Law of Demeter is an important guideline for software development that helps create more modular and easier-to-understand systems. By limiting communication between objects, we can create more robust and easier-to-maintain and modify code. However, it is important to apply the principle appropriately, considering the specific needs of each use case.