Let’s consider some classes Although this works, this implementation of the We can easily fix this by adding a method in class Now, class The Law of Demeter is formally defined in a paper published in 1989 [1]. It provides two definitions of the rule: the official, which is a bit cryptic and you can find in the reference, and another that even the authors believe is “the most natural way to state the Law”<\/em>, that goes like this:<\/p>\n\n\n\n For all classes C, and for all methods M attached to C, all objects to which M sends a message must be:<\/p>\n\n\n\n (Objects created by M, or by functions or methods which M calls, and objects in global variables are considered as arguments of M.)<\/p>\n<\/blockquote>\n\n\n\n I will complement this with some examples of function calls that adhere to the Law of Demeter:<\/p>\n\n\n\n If a method M receives an object as argument, the Law of Demeter allows calling methods on this object.<\/p>\n\n\n In some languages, like Python, methods explicitly include a As we saw in a previous article, we should usually prefer to follow the Dependency Inversion principle and inject dependencies, instead of creating objects inside other classes.<\/p>\n\n\n\nHouse<\/code>, Room<\/code> and SmartLight<\/code>:<\/p>\n\n\n\n<\/figure>\n\n\n\n
House<\/code> implements the illuminate_rooms<\/code> method to turn on the lights in every room. When called, it finds the light object on a specific room, and calls the turn_on<\/code> method.<\/p>\n\n\n\nclass House\n ...\n def illuminate_rooms\n @kitchen.light.turn_on\n end\nend\n<\/pre><\/div>\n\n\n
illuminate_rooms<\/code> method breaks the Law of Demeter because class House<\/code> is sending a message (turn_on<\/code>) on an object (light<\/code>) that it’s not directly associated with.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Room<\/code> to hide its implementation details, and call it from class House<\/code>:<\/p>\n\n\n\nclass Room\n ...\n def illuminate\n @light.turn_on\n end\nend\n\nclass House\n ...\n def illuminate_rooms\n @kitchen.illuminate\n end\nend\n<\/pre><\/div>\n\n\n
House<\/code> emits a message to kitchen<\/code>, one of its member variables, and so does class Room<\/code> when it calls @light.turn_on<\/code>. The Law of Demeter is then satisfied, as we are only making function calls on direct dependencies of the classes.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Formal Definition<\/h3>\n\n\n\n
\n
\n
M’s arguments<\/h5>\n\n\n\n
\nclass Class_C\n ...\n def method_M(argument_object)\n argument_object.message()\n end\nend\n<\/pre><\/div>\n\n\n
M’s self argument<\/h5>\n\n\n\n
self<\/code> argument that corresponds to the method’s class. Other programming languages do this implicitly. Irrespective of how this is done, what this rule says is that methods in a class can call methods on the same class.<\/p>\n\n\n\nclass ClassC\n ...\n def method_M\n another_method\n end\n\n def another_method\n ...\n end\nend\n<\/pre><\/div>\n\n\n
Objects created by M<\/h5>\n\n\n\n