in order for the same method invocation to produce different behavior, the state mode is in the proxy (surrogate) the implementation (implementation) for which it is switched over the life cycle. This is a way to optimize the implementation of code when you find that you have to do a lot of testing before deciding how to implement either method. --Objects decoupling (object decoupling)
For example : fairy tale The Frog Prince contains an object (a creature) whose behavior depends on its own state. You can use a Boolean (Boolean) value to indicate its state, and the test program is as follows:
State mode: Changes the behavior of an object, an object that is used to change the class (state).
Indications: the (same) conditional (expression) code appears in almost all methods. However, the Greet () method (and all the other square methods that must test the Isfrog value before completing the Operation ) eventually produce a whole bunch of hard-to-handle code. If you delegate these operations to a State object that can be changed, the code is much simpler.
The following code shows the basic structure of the state pattern:
in the main () function, the first implementation is used, and then the second implementation is transferred. When you implement state mode yourself, you encounter a lot of detail, and you have to choose the right implementation method based on your needs , such as whether it is exposed to the calling client and how the state changes. In some cases (such as Swing's LayoutManager), the client can directly pass in the object, but in the Kissingprincess2.java case, the state is not visible to the client.
In addition, the mechanisms used to change the state may be simple or complex-such as state machinery , where a series of States and different mechanisms for changing states are described. The example of the LayoutManager of Swing mentioned above is very interesting, it also embodies the behavior of strategy mode and state mode. The difference between Proxy mode and state mode is that they solve different problems. That's how it's described in design mode.
Proxy mode for the general application of:
1> Remote Proxy provides a local proxy for an object in a different address space. The RMI compiler (rmic) automatically creates a remote proxy for you when creating stubs and skeletons.
2> virtual Proxy, which, if needed, is used when creating complex objects "delay start Start (lazy initialization)".
3> Protection agent (Protection proxy) for you do not want the client programmer to have full control over the generation Objects (Proxied object).
4> Smart Reference (Smart Reference). Provides additional actions when accessing a Proxied object.
For example:
It can be used to count references to specific objects, enabling write-time Replication (copy-on-write), thus avoiding object aliases (objects aliasing). A simpler example is to record the number of times a particular method has been called. You can think of reference (reference) in Java as a protection agent that controls access to the actual objects allocated on the heap (and guarantees that you won't be using a null reference (null reference)). Rewrite: In design mode, the Proxy mode and State mode are considered to be irrelevant, because the structure given by the book to implement the two patterns is completely different (I think this implementation is somewhat arbitrary). the state mode, in particular, uses a separate implementation hierarchy, but I don't think it's necessary unless you assume that the implementation code is not controlled by you (which is, of course, a possibility, but if the code is controlled by you, It is also more concise and practical with a single base class). In addition, the proxy mode does not require a common base class, because the surrogate object simply controls access to the Proxied object. Despite the differences in detail, both the proxy mode and the state mode use a proxy (surrogate) to pass the method call to the implementation object. "
Example code for explaining state design patterns in Java
