The scene I saw at the barbecue stall at the gate of the community, because there are too many people who want to eat barbecue, they all hope to be late for the meat skewers as soon as possible, and the owner of the barbecue is alone, so it is a bit confusing. That's not all, the boss is alone, and there is one person who comes, he may not remember who has paid or not, how many strings he wants, whether it needs to be spicy, and so on. Everyone stood there, nothing happened, so they all stared at the barbecue, which one had more skewers, which one was less, which one was well-grilled, and which one was burnt clearly, so picky would follow. to. This is what is often called 'tight coupling' in programming. The 'tight coupling' of the client and the kebab owner makes it error-prone, confusing, and finicky.
This is actually the tight coupling of the 'behavior requester' and the 'behavior implementer'.
We need to record who wants a few skewers of mutton, whether there are any special requirements (spicy or not), whether they have paid or not, and who comes first. This is actually equivalent to recording the request, and it should be a log. If someone needs to back out the request, or ask for a re-roast, it's the equivalent of undo and redo.
Therefore, the tight coupling of 'action requester' and 'action implementer' is not suitable for request queuing or request logging, and support for revocable operations. How should I do it?
We are the requester of barbecue, and the master of barbecue is the implementer of barbecue. For opening a store, do we need to watch the realization process of barbecue?
We don't need to know who the roaster is, and we don't even need to see his face. We just need to tell the waiter who receives us what we are going to do, he can record our request, and then he will inform the roaster. Do. Moreover, due to the request we made, it is actually our order for meat. The above is a very detailed request for us. All customers have this order. The barbecue master can operate in sequence without confusion. will not be forgotten. When collecting money, neither overcharge nor undercharge.
The advantages don't stop here. When we changed the ten skewers of mutton into six skewers, it was enough. The waiter scratched on the small notebook and then went to inform the barbecue. This is actually an operation of undoing the behavior. Since there is a record, the final settlement will not be wrong. There are really many benefits to using a server to decouple the processing of customers and whether or not to roast meat.
This is the correspondence of roadside barbecue. If there are too many users and requests, it will be easy to mess up.
When the method of the store is implemented, it is necessary to increase the waiter class, but how to do it is indeed difficult. Whether it is kebabs, grilled chicken wings, or other barbecues, these are the behaviors of 'kebabs', that is, his methods. How to do it is implemented within the method, and you don't need to worry about it. But for the 'waiter' category, he actually sends an order according to the user's needs, saying: "Someone wants ten mutton skewers, and someone wants two chicken wings", these are all orders. . .
It means that the methods in the 'kebab person' class are respectively Ctrip multiple command classes, then they can be requested by the 'waiter'.
These commands are actually almost the same style, so you can generalize an abstract class and let the 'waiter' just issue orders to the abstract 'command'. The specific order, that is, what to bake, is up to the customer to decide.
1. Loosely coupled design
The above program basically implements the code, but there are several problems. First, the real situation is not that the user orders a dish, and the waiter informs the kitchen to make one. It is scientific, it should be after ordering the barbecue, the waiter One notification to make; second, if the chicken wings are gone at this time, it should not be the customer to judge whether there is any, the customer should know if there is any, it should be the waiter or griller to reject the request; third, what did the customer order? For barbecues or drinks, it is necessary to record a log for billing, including later statistics; fourth, customers may consider canceling some meat skewers that have not been made because they ordered too many skewers.
Second, loose coupling
3. Command mode
Command mode (Command), which encapsulates a request as an object, allowing you to parameterize clients with different requests; queue or log requests, and support undoable operations.
The role of command mode:
First, it makes it easier to design a command queue; second, it makes it easier to log commands if needed; third, it allows the party receiving the request to decide whether to deny the request; fourth, Can undo and redo requests easily; Fifth, since adding new concrete command classes does not affect other classes, it is easy to add new concrete command classes. Also, the command pattern separates objects that request an operation from objects that know how to perform an operation.
Agile development principles tell us not to add guess-based functionality to your code that you don't actually need. If it is not clear whether a system needs the command mode, generally do not rush to implement it. In fact, it is not difficult to implement this mode by refactoring when needed. Only when functions such as undo/restore operations are really needed, the original It only makes sense to refactor your code to command mode.