I don't know why many people written by the code is OO, in fact, using Class this keyword to cover the habit of structured programming. I personally think this is simply insult to this technology. When designing OO, find a variety of Domain Class or Business Class should be relatively easy, such as nominal law, etc. It is also the most interesting OO to solve the communication problem between the object. Because the result of not design is how the object does not know how to communicate, or if you want to communicate needs to expose a lot of internal state. Each object or class that controls this type of communication needs to be processed according to different situations, and write a bunch of IF ELSE is normal. It is really difficult to maintain. . . Another is to design excessive design, the result is an object requirement and countless object communication, and the result is DECOUPLE from this object's individual perspective, but from the perspective of the system and the communication Objects, high coupling, especially if it is a communication communication, if you modify the middle object that day, can you maintain your previous communication, to re-check, dangerous is very high. Thus, based on the above problems, behavioral mode functions, it can decouple objects or classes, especially those in different levels, especially the effect, like a famous MVC, OBSERVER mode variant. 1. Responsible chain mode. This mode is relatively simple, but is more practical in some occasions. The feeling of people, the whole process is like playing games, seems to be called "Board". We will explain that if the school conducts a school-wide scope. The starting point is the principal. After the principal knows what should be passed, the vice president tells another vice president, then. . . . The principal should tell this vice president, there is no reason, it is full of game rules, such as the first letter of the name. It is not a matter of the first vice president of the first letter to the first letter. This rule is determined by the person who specifies the rules of the game. The principal cannot do any decision. It is not possible to see a hierarchical relationship throughout the transfer. Of course this is a relatively single. Comparison, such as, if you want to reflect the relationship, you need to combine combination mode. The problem that this layer cannot be solved, and throws it to the upper layer. This is very like Java's abnormal mechanism. 2. Command mode. To be honest, from the individual, the Command mode is a specific application of Factory. I don't know if it is a personal understanding. When the same manner may be used in different places, it is best to define a commnad, so responsibilities, only need to modify one, avoid logic's non-uniform. 3. The parser mode. To be honest, I didn't understand the specific specialty. 4. Itecher mode. This mode is relatively kind because this has been used in STL. This model has a big problem that requires exposure to the internal state, so there is a troublesome language without Friend. The main purpose of this mode is to make a collection of different iterator classes as needed to achieve different requirements. If you modify the collection in order to adapt to different needs, the entire structure is too complicated. 5. Intermediary mode. This is actually a compromise when there is no way. If an action causes a variety of objects, and these changes are also associated, it is responsible with the object yourself, and in case some associations need to be modified, the entire system is very difficult to maintain. At this time, a full-time class is provided to handle this series of updates. The problem is that it is very likely that exposure-related internal states, and this intermediaries itself may become huge because of the responsibility. 6. Memo mode. If you do do, you need to do a UNDO operation, then some states before DO need to be retained, and then retrieve the action after UNDO. 7.
