PS: Input drives output. If you want to have continuous output, you need to have continuous input. Daily persistence may seem small, but what if you persist for a year or even longer? The result may not necessarily be great, but the process will definitely be fulfilling.
Today, let's review the design pattern of facade. When talking about the facade design pattern, we have to mention one of the six principles of design patterns, which is the Law of Demeter. This article will introduce the facade design pattern from the following aspects:
- The Law of Demeter
- Understanding the facade design pattern
- Implementing the facade design pattern
The Law of Demeter#
In development, we often encounter situations where the relationship between classes becomes increasingly close and the coupling becomes larger. This leads to the situation where a change in one class will also affect other classes. The Law of Demeter is used to regulate this phenomenon. So, what is the Law of Demeter?
The Law of Demeter, also known as the Least Knowledge Principle (LKP), states that an object should have the least knowledge about other objects.
There is a simpler definition for the Law of Demeter: only communicate with your immediate friends. Let me explain what immediate friends are. If two objects have a coupling relationship, we say that they have a friend relationship. Coupling relationships include dependencies, compositions, aggregations, etc. We call the classes that appear as member variables, method parameters, and method return values immediate friends. Classes that appear in local variables are not immediate friends, which means that unfamiliar classes should not appear in local variables.
Understanding the facade design pattern#
The facade design pattern is already being used in development, but it is not consciously recognized as the facade design pattern. For example, some functions are encapsulated for convenience and then provided uniformly by a management class. Most utility classes should use the facade design pattern.
In essence, the facade design pattern is to encapsulate widely used functions to avoid frequent coupling with other objects. By encapsulating and unifying the complexity of the subsystem, only one entry point is provided for external modules to call. This is the core of the facade design pattern.
Implementing the facade design pattern#
Scenario: In a tea house, customers A, B, C, etc. all want to brew and drink tea. Each customer needs to go through the following steps to brew a good cup of tea:
- Prepare tea set
- Prepare water
- Brew
Each customer has direct contact with tea sets, tea leaves, boiling water, etc. This clearly violates the Law of Demeter. We can use the facade design pattern to encapsulate the tea brewing process, which is like having a waiter in the tea house. When customers want to drink tea, they simply tell the waiter what kind of tea they want. Customers do not need to know the details of brewing tea. As long as they can drink the tea they want, it is enough. Let's implement the facade design pattern with this simple example. The tea brewing process is as follows:
/**
* Prepare tea set
* Created by jzman
* Powered by 2019/5/6.
*/
interface IPrepareTeaSet {
void prepareTeaSet();
}
class PrepareTeaSet implements IPrepareTeaSet {
@Override
public void prepareTeaSet() {
System.out.println("Preparing tea set...");
}
}
/**
* Prepare water
* Created by jzman
* Powered by 2019/5/6.
*/
interface IPrepareWater {
void prepareWater();
}
class PrepareWater implements IPrepareWater {
@Override
public void prepareWater() {
System.out.println("Preparing water...");
}
}
/**
* Brew method
* Created by jzman
* Powered by 2019/5/6.
*/
interface IBrewMethod {
void brewMethod(String tea);
}
class BrewMethod implements IBrewMethod {
@Override
public void brewMethod(String tea) {
System.out.println("Brewing... " + tea);
}
}
We encapsulate the tea brewing service and provide it to the outside world, as follows:
/**
* Tea house tea brewing service
* Created by jzman
* Powered by 2019/5/6.
*/
class TeaHouse {
// Unified tea brewing service
public static void drinkTea(String tea){
// Prepare tea set
new PrepareTeaSet().prepareTeaSet();
// Prepare water
new PrepareWater().prepareWater();
// Brew
new BrewMethod().brewMethod(tea);
}
}
Finally, customers can order the tea they want, as follows:
/**
* Test
* Created by jzman
* Powered by 2019/5/6.
*/
class FacadeMain {
public static void main(String[] args) {
// Customer A
TeaHouse.drinkTea("Black tea");
// Customer B
TeaHouse.drinkTea("Oolong tea");
}
}
The execution log is as follows:
Preparing tea set...
Preparing water...
Brewing... Black tea
Preparing tea set...
Preparing water...
Brewing... Oolong tea
This concludes the learning of the facade design pattern. Although we may write code like this in our daily business development, we are not consciously aware of the Law of Demeter and the facade design pattern. By introducing these concepts, we can subconsciously practice these rules and continuously improve our coding abilities.