查看 GoF 模式,我发现 State 和 Stategy 模式之间的相似之处相当惊人。两者都交换了多态类来修改行为。其他人发现了相同的吗?
确切的区别是什么?
查看 GoF 模式,我发现 State 和 Stategy 模式之间的相似之处相当惊人。两者都交换了多态类来修改行为。其他人发现了相同的吗?
确切的区别是什么?
状态和策略模式在某种意义上是相似的,它们都将行为封装在单独的对象中,并使用组合来委托给组合对象以实现行为,并且它们都提供了通过在以下时间更改组合对象来动态更改行为的灵活性运行。但是有一些关键的区别:
在状态模式中,客户端对状态对象一无所知。状态更改对客户端透明地发生。客户端只是在上下文中调用方法,上下文监督自己的状态。因为客户端不知道状态更改,所以每次由于状态更改而导致行为发生更改时,对客户端来说似乎上下文是从不同的类实例化的。作为模式的官方定义,该对象似乎会更改其类。该模式是围绕一系列明确定义的状态转换构建的。改变状态是模式存在的关键。
尽管策略模式提供了通过动态更改组合策略对象来更改行为的灵活性,但大多数情况下已经为每个上下文设置了适当的策略对象。即,即使该模式提供了一种动态更改组合策略对象的方法,但对它的需求并不大。即使必须这样做,也是客户进行更改。客户端将调用上下文的 setter 方法并传递新的策略对象。因此,行为变化对客户端不透明,由客户端发起和控制。该模式不鼓励像状态模式那样进行一系列明确定义的行为更改。客户端知道策略对象,通常会在创建策略对象时在上下文中设置适当的策略对象。
有关其他信息,请参阅以下链接http://myrandomsparks.blogspot.in/2012/05/strategy-vs-state-pattern.html
策略模式决定“如何”执行某些动作,状态模式决定“何时”执行它们。
通过使用状态模式,状态持有(上下文)类不再需要知道它是什么状态或类型以及可用的状态或类型。这意味着该类遵循开放-封闭设计原则 (OCP):对于存在的状态/类型的更改,该类是封闭的,但状态/类型对扩展是开放的。
通过使用策略模式,算法使用(上下文)类从如何执行特定任务(--“算法”)的知识中解脱出来。这个案例也创建了对 OCP 的遵守;该课程因有关如何执行此任务的更改而关闭,但该设计对添加其他算法以解决此任务非常开放