I don't know if my title is suitable. Anyway, I just want to express the design pattern clearly with a relaxed way to write. (Of course I don't know) anyway, I wrote .ok, now it is good. If you are in travel A traveler has a lot of states. These states will directly affect his behavior. For example, if you are hungry, you will eat. If you are thirsty, you will have water. If you are tired, you will continue to travel. And these states Switch. So what do you do? If it is me. I will think of the use of the switch. It's going to be intuitive and simple. OK then we do
Enum myState {hungry, adry, Tire, OK}; public class statemanager {
Private myState State = NULL;
Public void execute () {// Execute State Dothing DT = New Dothing (state); dt.execute (); // Switch State Swich (state) {Case MyState.hungry: State = MyState.Adry; Case MyState.adry: state = myState.TIRE; case myState.TIRE: state = myState.OK; case myState.OK:.. state = myState.HUNGRY;}}} public class DoThing {private myState state = null; DoThing (myState svalue) {state = Svalue;} public void execute () {SWICH (this.State) {Case MyState.hungry: console.writeline ("Eating"); Case MyState.adry: console.writeline ("Drink Water"); Case MyState.Tire : Console.writeLine ("Rest"); Case MyState.ok: Console.WriteLine ("Continue Travel");}}}
It can be seen from the above. The changes are directly affected. The things to have occurred. And the state is constantly changing. If it is not a simple assignment, it is necessary to do a lot of complex work. For example, POP Situation of the STPCONECTION STD statement seems to be cumbersome. Maybe you will say a write function, but the situation is not universal. It does not meet the object-oriented principle. Yes, we still have to do it to kick the switch. Because We have reason to believe that we have better ways to solve problems. We can see by the above. State is determined by a state manager and status itself. So. Therefore, how is the manager to manage more State. That is to say, the state must be abstract. In other words, it is to solve the problem using an interface or abstract class. IntersTeManager SM; MyState getState ();} This is an abstract state. It is the other specific state to be derived. And we must also rewrite the administrator object. Because the actual management object is required to complete the switch. Of course, we don't have to switch statements or if ... else if .... Use the object to come out for specific situations. Don't believe it ..... public class hungry_state: iMyState {void execute (stateManager SM) {// Switch to the next state sm.setState (new adry_state ()); SM. Execute ();} myState getState () {retuen myState.hungry;}} public class adry_State: iMyState {void execute (stateManager sm) {// Switch to the next state sm.setState (new adry_state ()); sm.execute ();} MyState getState () {retuen myState.adry;}} public class Tire_State: iMyState {void Execute (stateManager sm) { / / Switch to the next state sm.setState (new adry_state ()); sm.execute ();} MyState getState () {retuen myState.tire;}} public class ok_state: iMyState {void Execute (stateManager sm) {/ / Switch to the next state sm.setState (new adry_state ()); sm.execute ();} MyState getState () {retuen myState.ok;}} public class stateManager}} public class statate ms = null; void setState (iMyState IMS ) {Ms = IMS;} void execute () {ms.execute (this); dt.ms.getState ()); dt.execute ();}}
At this point, the manager is also refacting. This way we do not use the switch statement. More suitable object-oriented principles are used.
