问题描述
策略设计模式与状态设计模式之间有什么区别?我正在网络上浏览了很多文章,但无法清楚地说明差异.
有人可以解释外行术语中的区别吗?
推荐答案
老实说,这两种模式在实践中非常相似,并且它们之间的定义差异往往会根据您的要求而变化.一些流行的选择是:
- 状态存储对包含它们的上下文对象的引用.策略没有.
- 状态被允许替换自己(即:将上下文对象的状态更改为其他事物),而策略则不是.
- 策略作为参数传递给上下文对象,而状态是由上下文对象创建的.
- 策略仅处理一个特定的任务,而状态为上下文对象提供的一切(或大多数所有内容)提供了基本实现.
"经典"实现将匹配列表中每个项目的状态或策略,但是您确实跨过具有两者混合的混合动力车.某个特定的状态是更状态还是策略最终是一个主观的问题.
其他推荐答案
- 策略模式实际上是关于有不同的 实现(基本上)同一件事的实施,以便 一个实现可以按照策略的要求替换另一个. 例如,您可能具有不同的排序算法 策略模式.对象的呼叫者不会根据 正在采用哪种策略,但是无论策略如何 是相同的(排序集合).
- 状态模式是关于根据 州,让呼叫者免于 适应所有可能的状态.因此,例如,您可能有一个 getStatus()方法将根据 对象的状态,但是该方法的来电者不必是 对每个潜在状态进行了不同的编码.
其他推荐答案
区别仅在于它们解决了不同的问题:
- 状态模式涉及 (状态或类型)对象是(in) - 它封装了状态依赖性行为,而
- 策略模式涉及 对象如何执行某个任务 - 它封装了算法.
实现这些不同目标的结构非常相似.两种模式都是与委托的组成的示例.
对其优势的一些观察:
通过使用 state 模式,状态挂态(上下文)类可以从的知识中解脱出什么状态或类型IT以及可用的状态或类型.这意味着该类遵守开放式设计原理(OCP):该类是为了更改状态/类型的更改而关闭的,但状态/类型对扩展开放.
通过使用策略模式,算法using(context)类可以从的知识中解脱出如何执行某个任务( - "算法").这种情况也会遵守OCP;对于如何执行此任务的更改,该类是关闭的,但是设计非常开放,可以添加其他用于解决此任务的算法.
这也可能改善了上下文类对单个责任原则(SRP)的遵守.此外,该算法很容易被其他类可重复使用.
问题描述
What are the differences between the Strategy design pattern and the State design pattern? I was going through quite a few articles on the web but could not make out the difference clearly.
Can someone please explain the difference in layman's terms?
推荐答案
Honestly, the two patterns are pretty similar in practice, and the defining difference between them tends to vary depending on who you ask. Some popular choices are:
- States store a reference to the context object that contains them. Strategies do not.
- States are allowed to replace themselves (IE: to change the state of the context object to something else), while Strategies are not.
- Strategies are passed to the context object as parameters, while States are created by the context object itself.
- Strategies only handle a single, specific task, while States provide the underlying implementation for everything (or most everything) the context object does.
A "classic" implementation would match either State or Strategy for every item on the list, but you do run across hybrids that have mixes of both. Whether a particular one is more State-y or Strategy-y is ultimately a subjective question.
其他推荐答案
- The Strategy pattern is really about having a different implementation that accomplishes (basically) the same thing, so that one implementation can replace the other as the strategy requires. For example, you might have different sorting algorithms in a strategy pattern. The callers to the object does not change based on which strategy is being employed, but regardless of strategy the goal is the same (sort the collection).
- The State pattern is about doing different things based on the state, while leaving the caller relieved from the burden of accommodating every possible state. So for example you might have a getStatus() method that will return different statuses based on the state of the object, but the caller of the method doesn't have to be coded differently to account for each potential state.
其他推荐答案
The difference simply lies in that they solve different problems:
- The State pattern deals with what (state or type) an object is (in) -- it encapsulates state-dependent behavior, whereas
- the Strategy pattern deals with how an object performs a certain task -- it encapsulates an algorithm.
The constructs for achieving these different goals are however very similar; both patterns are examples of composition with delegation.
Some observations on their advantages:
By using the State pattern the state-holding (context) class is relieved from knowledge of what state or type it is and what states or types that are available. This means that the class adheres to the open-closed design principle (OCP): the class is closed for changes in what states/types there are, but the states/types are open to extensions.
By using the Strategy pattern the algorithm-using (context) class is relieved from knowledge of how to perform a certain task (-- the "algorithm"). This case also creates an adherence to the OCP; the class is closed for changes regarding how to perform this task, but the design is very open to additions of other algorithms for solving this task.
This likely also improves the context class' adherence to the single responsibility principle (SRP). Further the algorithm becomes easily available for reuse by other classes.