To manage complexity, one idea is that a class should be designed so

that it does not need to know about and depend

upon almost every other class in the system.

That would increase coupling and make your system harder to maintain.

This naturally leads to the concept that classes should have

a narrow view of what other classes it knows.

By limiting which classes communicate with each other,

you can enforce the Principle of Least Knowledge on your system.

This principle is also realized in a rule known as The Law of Demeter.

The underlying idea of this law is that classes should know

about and interact with as few other classes as possible.

This means that any class should only communicate with its immediate friends.

These friends would be other classes that one class should only know about.

This notion is a little bit more abstract than other design principles,

but it is equally as important because it helps to

reduce coupling and provide stability to your systems.

The Law of Demeter is actually composed of different rules which we will examine,

as well as how the Law of Demeter can be violated.

The rules in the Law of Demeter are used to provide a guideline

as what kind of method calls a particular method can make.

The First Rule we will look at states that a method, M,

in an object, O,

can call on any other method within O itself.

This rule is fairly simple and it makes logical sense.

A method encapsulated within a class is allowed to call

any other method that is also encapsulated within the same class.

In this example, method M is allowed to call the method

N and both methods are part of the same class.

The Second Rule states that a method,

M, can call the methods of any parameter,

P. Since a method parameter is considered local to the method,

the parameter can be considered a friend.

So methods in the class for the parameter can be called.

The method M in your class O has a parameter P of type Friend.

The Law of Demeter will allow at method M to invoke any method of the Friend class.

The Third Rule of the Law of Demeter,

is that a method, M,

can call a method, N,

of an object, I,

if I is instantiated within M. This means that if

a method makes a new object then the method can use that new object's methods.

The object is considered local to the creating method.

The same way an object is considered local when it is a parameter.

In this example, the method M creates a new local instance of the Friend class,

since the Friend object is a local to method M,

you are allowed to call any method of the Friend class.

In addition to local objects,

the Fourth Rule states that any method, M,

in object, O, can invoke methods of any type of object that is a direct component of O.

This means that a method of a class can call

methods of the classes of its instance variables.

Since class O has a direct reference to the Friend class,

any method inside of O is allowed to call any method of class Friend.

The Law of Demeter appears to be a complicated and abstract concept,

but all the rules come down to the principle that you should not allow a method to

access another method by reaching through an object.

This means that a method should not invoke methods of any object that is not local.

We have just looked at what the law considers to be a local object.

These objects should be passed in through

a parameter or they should be instantiated within a method,

or they should be an instance variables.

This allows methods to directly access the behaviors of local objects.

The term "reaching through" means that you'd need

to use another object to pass along your request.

Or that you are using methods of objects that are

considered outside your immediate friends.

These conditions, commonly occur when you have

a chain of method calls to objects you shouldn't know

about or when you use methods from

an unknown type of object that is returned to you from your local method call.

This is an example of training method calls to an object that does not belong to you.

The driver knows about the car class but

the engine of the car is not a component of the driver.

Therefore, the driver should not be calling methods of the engine.

You should not be accessing methods of objects

that are not within your immediate circle friends.

Think about it this way, when you drive a car,

you don't issue individual commands to every component of the car.

You should simply just tell the car to drive and

the car itself will know how to deal with its components.

The other way you can reach through an object is when your method receives an object of

an unknown type as a return value and you make method calls to the returned object.

Returned objects must be of the same type as: those declared in the method parameter,

those declared and instantiated locally in the method,

or those declared in instance variables of the class that encapsulates the method.

Again, this is because you do not know

about the object prior to it being returned to you.

So, you shouldn't be using something you don't know about.

This idea that you should only use returned objects that match

the types of local objects is demonstrated in this example.

This driver class knows about the car class,

which is declared in an instance variable, and also,

vehicle rental stores, which is declared as a parameter.

However, since it does not create a new instance of a motorcycle,

your driver should not be able to operate that type of vehicle.

Since you have specified that the type of vehicle the driver can use is a car,

the driver should only be able to operate a car.

This would be similar to someone who has never driven

a motorcycle going into a store and renting one to drive around.

This person doesn't know anything about motorcycles.

So, why should they be allowed to rent and operate one?

The Law of Demeter defines how classes should interact with each other.

They should not have full access to

the entire system because this causes a high degree of coupling.

According to Law of Demeter,

a class should only interact with those that are considered its immediate friends.

Classes should know as little as possible about your system as a whole.

This will help reduce the amount of coupling and prevent

unwanted effects from cascading through your entire system.

The Law of Demeter, otherwise known as the Principle of Least Knowledge,

creates a set of guidelines that will help you

determine how your classes should interact.

This design principle focuses more broadly on how method calls should be

made instead of on specific ways to structure the design of your system.

According to this design principle, a method, M,

of an object should only call other methods if they

are: encapsulated within the same object,

encapsulated within an object that is in the parameters of M,

encapsulated within an object that is instantiated inside of M,

or encapsulated within an object that is reference in an instance variable of

the class for M. While the Law of Demeter does help reduce coupling,

it also means that you will need to spend

more time when designing and implementing your system.

Sometimes, it might not be feasible to always follow

these rules due to limitations on your time and resources.

Other times, some degree of coupling may be unavoidable,

at which point, you'll need to decide how much coupling is tolerable.

When you're designing your systems,

you should do your best to practice

these design principles as they will help you create more flexible,

reusable and maintainable systems.

2.3.6 – Principle of Least Knowledge

Design Patterns

Rencontrer les enseignants