状态模式
定义
允许一个对象在其内部状态改变时改变它的行为，这个对象看起来就像改变了它的类一样。
优点
- 状态模式将与特定状态相关的行为局部化到一个状态中，并且将不同状态的行为分割开来，满足“单一职责原则”。
- 减少对象间的相互依赖。将不同的状态引入独立的对象中会使得状态转换变得更加明确，且减少对象间的相互依赖。
- 有利于程序的扩展。通过定义新的子类很容易地增加新的状态和转换。
缺点
- 状态模式的使用必然会增加系统的类与对象的个数。
- 状态模式的结构与实现都较为复杂，如果使用不当会导致程序结构和代码的混乱。
- 虽然状态模式可以很好的处理行为受状态约束的情况，但相应的对象的状态也会增加，所以在实际项目中使用的时候，要权衡利弊，考虑它对你的设计带来的后果影响是否可以接受。如果状态太多比如十几个或者几十个，还是建议不要使用了。
场景
行为随着状态的改变而改变的时候，这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。
条件、分支判断语句的替代者，在程序中大量使用 switch 语句或者if-else判断语句会导致程序结构不清晰，逻辑混乱，使用状态模式可以很好地避免这一问题。
代码
package State import "fmt" type Context struct { state State } func NewContext() *Context { return &Context{state: &ConcreteStateA{}} } func (c *Context) SetState(state State) { c.state = state } func (c *Context) Handle() { c.state.Handler(c) } type State interface { Handler(*Context) } type ConcreteStateA struct { } func (c *ConcreteStateA) Handler(context *Context) { fmt.Println("当前状态是A") context.SetState(&ConcreteStateB{}) } type ConcreteStateB struct { } func (c *ConcreteStateB) Handler(context *Context) { fmt.Println("当前状态是B") context.SetState(&ConcreteStateC{}) } type ConcreteStateC struct { } func (c *ConcreteStateC) Handler(context *Context) { fmt.Println("当前状态是C") context.SetState(&ConcreteStateA{}) }
package State import "testing" func TestContext_Handle(t *testing.T) { context := NewContext() context.Handle() context.Handle() context.Handle() context.Handle() context.Handle() }
其他设计模式
设计模式Git源代码
00简单工厂模式
01工厂方法模式
02抽象工厂模式
03外观模式
04建造者模式
05桥接模式
06命令模式
07迭代器模式
08模板模式
09访问者模式
10备忘录模式
11责任链模式
12中介模式
13原型模式
14状态模式
15策略模式
16享元模式
17组合模式
18解释器模式
19单例模式
20适配器模式
21代理模式
22装饰器模式
23观察者模式
