Design Patterns not mentioned in the gof book (1): Archetype
I haven't come up with a Chinese name for this design pattern for a long time. Even if I forget it, sometimes it is easier to understand the original version.
To put it simply, the archetype Design Pattern aims to separate the business processing logic from the specific implementation, so at least two participants are required: decorator and delegate,
They all implement the same interface. decorator is responsible for processing the business logic, while delegate is responsible for specific implementation.
During the processing, the specific implementation will be delegated to delegate.
(Note: The decorator here does not refer to the "decorator" design mode)
Let's use an example. Suppose the system has an interface for recording various events:
Public InterfaceEventrecorder {
//Record event content
Public VoidRecord (string event );
}
Two abstract classes are introduced to separate processing logic and specific implementation:
Public Abstract Class Eventrecorderdecorator Implements Eventrecorder {
Protected Eventrecorderdelegate delegate;
Public Void Setdelegate (eventrecorderdelegate delegate ){
This . Delegate = Delegate;
}
}
Public Abstract Class Eventrecorderdelegate Implements Eventrecorder {
}
The following are two simple decorator classes:
// Simple event logging
Public Class Simpleeventrecorder Extends Eventrecorderdecorator {
Public Void Record (string event ){
// Append the current date to the event content
Event = Getdate () + Event;
// When the content is too long, it is omitted.
Event = Ellipsetext (event );
// Record event content
Delegate. Record (event );
}
}
// Complex Event Logging
Public Class Complicateeventrecorder Extends Eventrecorderdecorator {
Public Void Record (string event ){
// Append the current date to the event content
Event = Getdate () + Event;
// Append the current exception information to the event content.
Event = Event + Getexceptiontext ();
// Append the current memory and CPU usage to the event content
Event = Event + Getmachinestatus ();
// When the content is too long, it is omitted.
Event = Ellipsetext (event );
// Record event content
Delegate. Record (event );
}
}
As you can see, the last step is handed over to the eventrecorderdelegate object. This step is the "specific implementation" mentioned earlier. It is possible to record the event content in the following ways:
1. record to the database
2. Record it to a local file
3. Send by email
4. Send to remote server
Therefore, we need to create four eventrecorderdelegate Derived classes to implement these record methods:
Public Class Recordeventtodatabase Extends Eventrecorderdelegate {
Public Void Record (string event ){
// Write records to the database
}
}
Public Class Recordeventtofile Extends Eventrecorderdelegate {
Public Void Record (string event ){
// Write records to files
}
}
Public Class Recordeventbyemail Extends Eventrecorderdelegate {
Public Void Record (string event ){
// Send records to the specified email address
}
}
Public Class Recordeventtoremoteserver Extends Eventrecorderdelegate {
Public Void Record (string event ){
// Send records to remote servers
}
}
The following is a factory that generates event record objects:
Public Class Eventrecorderfactory {
Public Static Eventrecorder create ( Int Type, Int Flag ){
Eventrecorderdelegate delegate = Null ;
Eventrecorderdecorator decorator = Null ;
If (Type = 0 )
Decorator = New Simpleeventrecorder ();
If (Type = 1 )
Decorator = New Complicateeventrecorder ();
If (Flag = 0 )
Delegate = New Recordeventtodatabase ();
If (Flag = 1 )
Delegate = New Recordeventtofile ();
If (Flag = 2 )
Delegate = New Recordeventbyemail ();
If (Flag = 3 )
Delegate = New Recordeventtoremoteserver ();
// Set proxy
Decorator. setdelegate (delegate );
}
}
We can see from the example that there are two business processing logic and four specific implementations, which constitute eight event recording methods. In addition, four specific implementation methods are used separately, and there are actually 12 recording methods.