I. Examples
Taking my previous File System (FileSys) as an example:
A file system is an independent system that provides a set of core file operations.
In addition to the file system, there are four subsystems, namely the KillVirus, ZipFile, EncrypeFile, and BurnCD, which are independent of each other, but it can also be used as part of the main system functions.
Assume that the customer needs two execution modes for my file system: full mode and simple mode.
The full mode requires the anti-virus sub-, compression, encryption, and burning functions.
In simple mode, you only need to burn the virus.
First design:
The file system manages all its subsystems and meets customers' requirements.
At the beginning, we designed the file system based on the above structure. This file system (FileSys) needs to manage and organize the four subsystems on its own. The problem is that the subsystem changes a lot, especially after reconstruction, the interface also changes, and the file system needs to be modified accordingly. The most troublesome thing is that sometimes a sub-system needs to separate many small classes, which is a good thing for subsystems. But for FileSys, calling becomes more and more complex and difficult.
This design problem is: file systems and subsystems are too coupled!
Design 2:
Later, we developed an independent Middle Layer for unified management of these subsystems and provided relatively simple interfaces to reduce dependencies between them.
Code implementation:
[Cpp] view plaincopyprint? // Anti-Virus
Class KillVirus
{
Public:
Void Operation1 () {cout <"Antivirus" <endl ;}
};
// Compression
Class ZipFile
{
Public:
Void Operation2 () {cout <"compression" <endl ;}
};
// Encryption
Class EncryptFile
{
Public:
Void Operation3 () {cout <"encrypted" <endl ;}
};
// Burn
Class BurnCD
{
Public:
Void Operation4 () {cout <"burn" <endl ;}
};
// High-level interface
Class OperatorWapper
{
Public:
// Fully functional
Void MethodA ()
{
KillVirus kill;
ZipFile zip;
EncryptFile encrypt;
BurnCD burn;
Kill. Operation1 ();
Zip. Operation2 ();
Encrypt. Operation3 ();
Burn. Operation4 ();
}
// Simple functions
Void MethodB ()
{
KillVirus kill;
BurnCD burn;
Kill. Operation1 ();
Burn. Operation4 ();
}
};
// Test code
Int main ()
{
OperatorWapper op;
Op. MethodA (); // fully functional
Op. MethodB (); // Simple Function
Return 0;
}
// Anti-Virus
Class KillVirus
{
Public:
Void Operation1 () {cout <"Antivirus" <endl ;}
};
// Compression
Class ZipFile
{
Public:
Void Operation2 () {cout <"compression" <endl ;}
};
// Encryption
Class EncryptFile
{
Public:
Void Operation3 () {cout <"encrypted" <endl ;}
};
// Burn
Class BurnCD
{
Public:
Void Operation4 () {cout <"burn" <endl ;}
};
// High-level interface
Class OperatorWapper
{
Public:
// Fully functional
Void MethodA ()
{
KillVirus kill;
ZipFile zip;
EncryptFile encrypt;
BurnCD burn;
Kill. Operation1 ();
Zip. Operation2 ();
Encrypt. Operation3 ();
Burn. Operation4 ();
}
// Simple functions
Void MethodB ()
{
KillVirus kill;
BurnCD burn;
Kill. Operation1 ();
Burn. Operation4 ();
}
};
// Test code
Int main ()
{
OperatorWapper op;
Op. MethodA (); // fully functional
Op. MethodB (); // Simple Function
Return 0;
}
Ii. Appearance Mode
Definition: provides a consistent interface for a group of interfaces in the subsystem. The appearance mode defines a high-level interface, which makes the subsystem easier to use.
In short, it is the concept of hierarchy.
Note:
1. at the initial stage of design, we should consciously separate different layers. For example, a common three-tier architecture is to establish a Facade between the data access layer, business logic layer, and presentation layer, the complex subsystem provides a simple interface to reduce coupling.
2. In the development phase, subsystems tend to become more and more complex due to constant refactoring. With more appearances, Facade can provide a simple interface to reduce dependencies between them.
3. in the maintenance phase, the system may be very difficult to maintain and expand. At this time, you can develop an appearance class for the new system, to provide clear and simple interfaces for the design of rough or highly complex legacy code, so that the new system can interact with the Facade object, and the Facade and legacy code can interact with all the complicated work.
Author lwbeyond