When the state of certain objects often faces changes (changes in state will also mean changes in behavior), how to manage these changes while maintaining the stability of high-level modules. This is what the "state change" model needs to address.
The State mode is actually similar to the strategy mode, except that the strategy mode is aimed at the change of the algorithm, and here is the change of the object state, which is basically the same. (The jump of the company software interface function seems to be the state mode used, with a Class to store the operation and what interface should be the next. Each node becomes a single class, use the setting of the next interface to connect)
The mode is to put all the behaviors related to a specific state into a State sub In the object, when the state of the existing object is switched, the corresponding object is switched while maintaining the State interface to realize the specific operation and state. Introducing different objects between different states makes state transitions more clear and simple, and less error-prone
(note; in order to save the cost of objects, you can use the singleton mode to share an object globally)
for example; [temporarily total There are 3 states; open, close, connect] and there are two methods Opr1, Op2.
The
concept of memo (some obsolete mode) ; in the process of software construction, the state of some objects is in the process of transformation, because some need to go back to a certain state point before the object, if some public interfaces (that is, public variables) are used To save, so that the specific details are exposed. Not conducive to packaging.
The memo is actually a specially designed class, Memento class to record and save the state of the class.
The 26 design patterns published in 1994 have basically become obsolete with the rapid development of information. Most of them now use serialization for storage.