Bridge Mode of grinding design mode-1

ArticleDirectory

• 1.1 send a prompt message
• 1.2 non-use mode solution
• 1.3 what's the problem?

To write a new and familiar design pattern. It is also a very practical design pattern, that is, the Bridge pattern.

Many friends are not familiar with this design pattern. Many people often see or subconsciously use this pattern, but do not know it. The bridge mode is a very practical mode. Write it as follows.

 

 

Bridge Mode (BRIDGE) 1 Scenario problem 1.1 send a message

Consider the actual business function of sending a prompt message. Basically, all systems with business process processing have such functions. For example, if someone has a new job, a message should be sent to remind him.
From the business perspective, messages are divided into common messages, urgent messages, and urgent messages. Different types of messages have different service functions. For example, a urgent message is added to a message, in addition to adding urgent messages, the urgent messages will also be recorded as a reminder, and will continue to be urged as soon as they are not completed. In terms of message sending methods, there are also systems such as short messages, short messages, and emails.
How can we implement the function of sending prompt messages?

1.2 non-use mode solution

1: simplified version
First, consider implementing a simple version. For example, if a message is used to send a common message, the method of sending the message first is to implement short messages and emails in the system. Other functions will be added after this version is complete. This simplifies the problem and makes it easier to implement it.
(1) because there are two different implementation methods for sending common messages, in order to allow external operations to be unified, the message is designed as an interface and then consists of two different implementation classes, the system implements the short message mode and the mail message sending mode respectively. In this case, system structure 1 is shown:

 

Figure 1 Simplified Version System Structure

 

Let's take a look at the general implementation.

(2) Let's take a look at the unified message interface, for example.CodeAs follows:

 
/*** Unified message interface */public interface message {/*** send message * @ Param message the content of the message to be sent * @ Param touser the recipient of the Message */ public void send (string message, string touser );}
 

 

(3) let's take a look at the two implementation methods. Here we just want to show you how to send an email or an on-site short message. The sample code is as follows:

/*** Send common messages through short messages on the site */public class commonmessagesms implements message {public void send (string message, string touser) {system. out. println ("Send message '" + message + "' to" + touser "by using short messages in the station );}}
 

Similarly, you can send common messages by email. The sample code is as follows:

 
/*** Send a common message by email */public class commonmessageemail implements message {public void send (string message, string touser) {system. out. println ("Send message by email '" + message + "' to" + touser );}}
 

2: Enable sending of urgent messages

The above implementation looks very simple, right. Next, we will add the function of sending urgent messages. There are also two ways to send messages, that is, intra-site short messages and email.
Different from common messages, an urgent message automatically adds an urgent message to the message before sending the message. In addition, a monitoring method is provided for the urgent message, the client can use this method to understand the progress of handling urgent messages at any time, for example, whether the corresponding personnel receive the information and whether the corresponding work has been carried out. Therefore, a new interface needs to be extended for urgent messages. In addition to the basic message sending function, the monitoring function needs to be added. At this time, the system structure 2 is shown in:
 

 

 

Figure 2 system structure after an urgent message is sent

(1) first, let's look at the Extended Interface for urgent messages. The sample code is as follows:

 
/*** Abstract interface of the urgent message */public interface urgencymessage extends message {/*** monitor the processing process of a message * @ Param messageid the number of the message to be monitored * @ return contains the monitored data objects, here, we use object */public object Watch (string messageid );}
 

 
(2) the corresponding implementation method is either sending station short messages or email. Two implementation classes are also required to implement the two methods respectively. First, let's look at the station short messages, the sample code is as follows:
 

 
Public class urgencymessagesms implements urgencymessage {public void send (string message, string touser) {message = "urgent:" + message; system. out. println ("Send message '" + message + "' to" + touser) by using short messages in the station;} public object Watch (string messageid) {// obtain the corresponding data, organize it into a monitored data object, and return NULL ;}}
 
Let's take a look at the emai method. The sample code is as follows:
 
 
Public class urgencymessageemail implements urgencymessage {public void send (string message, string touser) {message = "urgent:" + message; system. out. println ("Send message via email '" + message + "' to" + touser);} public object Watch (string messageid) {// obtain the corresponding data, organized into monitoring data objects, and return NULL ;}}
 
 
(3) In fact, the function of sending different messages may be used to send different messages, that is, to let the objects that implement the processing of urgent messages inherit the corresponding implementation of common messages, this is not done to make the structure simpler and clearer.
 
1.3 what's the problem?
 
The above implementation seems to be able to meet the basic functional requirements, but is this implementation good? Is there any problem?
Let's continue to add the function implementation. For the sake of simplicity, we will not proceed with the code diagram. We can see the implementation problems through the implementation structure.
1: add more urgent messages.
Urgent messages do not need to be viewed and processed. As long as they are not completed, they are directly urged. That is to say, for urgent messages, the pushing function must be added based on the processing of common messages. In addition, there are two methods for sending urgent messages and pushing messages. The corresponding implementation methods are short messages and emails in the sending site. The system structure is shown in 3:
 
 
 
Figure 3 system structure after an urgent message is sent
 
 
Looking at the system structure above, we will find a very obvious problem: it is very inconvenient to extend the message processing through this inheritance method.
As you can see, when processing an urgent message, you must implement the short message and email processing methods in the station, because the service processing may be different. When processing an urgent message, in addition, the short message and email processing methods must be implemented.
This means that the two processing methods must be implemented each time the message processing is extended in the future. Is it very painful? This is not enough. What if you want to add a new implementation method? Continue to look down.
 
 
2: add more processing methods for sending mobile phone messages
 
 
If you see the above implementation, you still feel that the problem is not very big, continue to complete the function, add the processing method for sending the mobile phone message.
Observe the current implementation carefully. If you want to add a new message sending method, you must add the processing of the sent mobile phone message in each abstract implementation. That is to say, the processing of common messages, urgent messages, and urgent messages can all be sent through mobile phones. This means that three implementations need to be added. In this case, system structure 4 is shown as follows:
 
 
 
 
 
Figure 4 system structure after mobile phone messages are sent
Now I can see the major problems with this implementation method.
 
 
3: Summarize the problems
The implementation method of extended by inheritance has an obvious drawback: it is not easy to expand the types of messages. Different types of messages have different services, that is, they have different implementations, in this case, all different message sending methods are required for each type of message.
What's more terrible is that if you want to add a new message sending method, all types of messages must be added to the implementation of this new sending method.
What if I want to extend the business functions? For example, to send messages to a group, that is, multiple messages can be sent at a time, which means that the changes have to be made in many places, which is terrible.
So how can we achieve both functionality and flexible scalability?
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
======== Not complete to be continued ========