State in travel)

 

I don't know if my title is appropriate. no matter. I just want to express the design pattern in a simple way. (Of course, I may not know) how to write it. OK, now. if a traveler has many statuses during a trip. these statuses will directly affect his behavior. for example. if you are hungry, go to dinner. if you are thirsty, you need to drink water. if you are tired, you have to rest. if it is normal, you need to continue traveling. and these statuses are switched to each other. so what will you do? If it is me, I will first think of using the switch. It should be intuitive and simple. OK, then we will do that.

Enum mystate {hungry, Adry, tire, OK };
Public class statemanager {

Private mystate state = NULL;

Public void execute (){
// Execution status
Dothing dt = new dothing (State );
DT. Execute ();
// Switch Status
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 ("dinner ");
Case mystate. Adry:
Console. writeline ("Drinking Water ");
Case mystate. Tire:
Console. writeline ("break ");
Case mystate. OK:
Console. writeline ("Continue Travel ");
}
}
}

We can see from the above. status changes directly affect. what will happen. and the status is constantly changing. if you think it's not a simple assignment but a lot of complicated work in complex situations. for example, the switch statement in pop mailbox tcpconection is cumbersome. maybe you will write a function, but that is not general enough. and does not comply with the object-oriented principle. yes. The next thing we need to do is to kill the switch. we have reason to believe that we have a better solution.
We can see from the above. the status is determined by the Status manager and the status itself. therefore. it is important to consider how managers can manage more States. that is to say, the State must be abstracted. in other words, you must use an interface or abstract class to solve the problem.
Interface imystate {
Void execute (statemanager sm );
Mystate getstate ();
}
This is an abstract state. that is, other specific states must be derived to this point. in addition, we must rewrite the Administrator object. because the actual management object to complete the switch must be accused. of course, we do not need to switch the statement or if... else if ..... instead, we use an object to show the specific situation. if you don't believe it, just watch it .....
Public class hungry_state: imystate {
Void execute (statemanager sm ){
// Switch to the next status
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 status
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 status
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 status
SM. setstate (New adry_state ());
SM. Execute ();
}
Mystate getstate (){
Retuen mystate. OK;
}
}

Public class statemanager {
Private mystate MS = NULL;
Void setstate (imystate IMS ){
MS = IMS;
}
Void execute (){
Ms. Execute (this );
Dothing dt = new dothing (this. Ms. getstate ());
DT. Execute ();
}
}

At this point, the manager has also completed restructuring. In this way, we have not used the switch statement, but used the more appropriate object-oriented principle.