The human-array computer is undoubtedly one of the most stunning scenes in The Three-Body Problem. In the novel, "von Neumann" organized three soldiers into each gate component, ultimately mobilizing thirty million soldiers of "the First Emperor" to form a colossal computer of ten million gate parts, all in an attempt to solve the ultimate problem of the three-body system—predicting the next stable era.

Presenting microscopic, structured things in a macroscopic, systematic way often leaves a profound impact. Much like the transparent PC case designs that fascinate so many, I believe most people interested in computers, including myself, can hardly resist their charm.

Today, from a semi-open perspective and using the lens of a computer’s operation, let’s appreciate the beauty of a computer while dissecting what the Facade Pattern is all about.

In a Nutshell

The Facade Pattern defines a consistent interface to shield the details of internal subsystems, so that the client only interacts with this interface without worrying about the internal complexities of those subsystems.

Hello, von Neumann

For the sake of simplicity, we can temporarily view a computer’s boot process as:

1. The CPU processes data
2. Memory loads data
3. The hard drive reads data

Suddenly, dizziness hits you, and you find yourself playing the role of von Neumann in The Three-Body Problem, tasked with designing the "Qin 1 Human-Array Computer" for the First Emperor. How would you go about it?

What? Do I even need to think?

Player von Neumann One can’t help but chuckle. Is this even a question? Object-oriented, let the First Emperor call whatever he wants—it can’t get any simpler than this.

But things don’t go as planned. A computer’s startup process is far from the simple assumption we just made.

Following this design, the "First Emperor" would have to personally issue detailed commands to thousands upon thousands of gate components. Once the Emperor grasped the real interaction behind this design, he promptly sent "von Neumann" to the guillotine.

Yes, I do need to think

The arrogant "von Neumann" player enters the game again, this time deep in thought. It seems the key to this level is hiding the internal implementation details of "Qin 1." How can I make the "First Emperor" comfortably be an emperor, rather than embedding him inside the "human-array computer"?
Aha!
I can provide a unified calling interface, acting as the facade class. Only it knows which subsystems handle the requests, delegating client calls to the appropriate subsystem objects.
"Zhao Gao, come here! His Majesty has a good job for you!"

Design

By transforming a group of complex interfaces into a single interface, the heavy lifting is handed to Zhao Gao (the facade class), while the First Emperor (the client) only needs to get the desired results from him.

Code Implementation

Processor

interface Processor {
   void execute();
}
class ProcessorUnit implements Processor {
   @Override
   public void execute() {
       System.out.println("Processor is executing instructions.");
   }
}

RAM

interface RAM {
   void load();
}
class RAMModule implements RAM {
   @Override
   public void load() {
       System.out.println("RAM is loading data.");
   }
}

DiskDrive

interface DiskDrive {
   void read();
}
class DiskDriveUnit implements DiskDrive {
   @Override
   public void read() {
       System.out.println("Disk drive is reading data.");
   }
}

StartupFacade (Zhao Gao)

class StartupFacade {
   private Processor cpu;
   private RAM memory;
   private DiskDrive disk;

   public StartupFacade() {
       this.cpu = new ProcessorUnit();
       this.memory = new RAMModule();
       this.disk = new DiskDriveUnit();
   }

   public void boot() {
       cpu.execute();
       memory.load();
       disk.read();
       System.out.println("System started successfully.");
   }
}

Client (First Emperor)

public class Client {
   public static void main(String[] args) {
       StartupFacade system = new StartupFacade();
       system.boot();
   }
}

Execution

Facade Pattern in MyBatis Source Code

In MyBatis, the Configuration class manages the global configuration information, including mappers, parameter mappers, result mappers, and more. The Configuration object is created during MyBatis startup and remains responsible for managing various configuration data throughout the application’s lifecycle.

During its creation, the Configuration object uses the MetaObject utility class to create a MetaObject instance, primarily for handling metadata operations on objects. MetaObject is a tool provided by MyBatis that facilitates accessing object properties, performing property assignment, retrieval, and judgment.

Specifically, MetaObject is used to handle attribute access and operations on configuration information, mappers, parameters, and results. Through MetaObject, you can dynamically get and set object property values without directly manipulating the objects themselves. This improves code flexibility and maintainability, making configuration management more convenient.

In essence, by creating a MetaObject, Configuration can easily manage and operate MyBatis’s configuration data, offering a flexible way to handle object property operations for more efficient and maintainable code.

When Configuration creates MetaObject, the Facade Pattern is employed.

Framework Design

Source Code Analysis

When Configuration creates a MetaObject, it calls the forObject method. If the object is not null, it essentially combines ObjectFactory, ReflectorFactory, and ObjectWrapperFactory, and performs further judgment and processing based on the actual situation.

Relevant Source Code

Conclusion

The Facade Pattern shields the details of subsystems from the outside, reducing the complexity for clients. In terms of coupling, it also makes the internal modules of subsystems easier to maintain and extend. When used appropriately, the Facade Pattern facilitates layered design and often works wonders in maintaining legacy systems.