战略设计模式和国家设计模式之间的区别是什么?我在网上浏览了不少文章,但看不出明显的区别。
有人能用外行的语言解释一下吗?
战略设计模式和国家设计模式之间的区别是什么?我在网上浏览了不少文章,但看不出明显的区别。
有人能用外行的语言解释一下吗?
当前回答
这是一个相当老的问题,但我也在寻找同样的答案,这就是我所发现的。
对于状态模式,让我们考虑一个中间播放器播放按钮的例子。当我们开始播放时,它开始播放,并让上下文意识到它正在播放。每次客户端想要执行播放操作时,他都会检查播放器的当前状态。现在客户端知道对象的状态是通过上下文对象播放的,所以他调用暂停状态对象的动作方法。客户端实现状态的部分以及它需要在什么状态上执行操作的部分可以被自动化。
https://www.youtube.com/watch?v=e45RMc76884 https://www.tutorialspoint.com/design_pattern/state_pattern.htm
在策略模式的情况下,类图的安排与状态模式相同。客户来此安排做一些操作。也就是说,不同的算法取代了不同的状态,比如需要对模式进行不同的分析。在这里,客户端告诉上下文它想做什么,用什么算法(业务定义的自定义算法),然后执行。
https://www.tutorialspoint.com/design_pattern/strategy_pattern.htm
两者都实现了开闭原则,因此开发人员可以向状态模式和新算法中添加新的状态。
但不同之处在于它们使用的是基于对象状态执行不同逻辑的状态模式。在战略的案例中有不同的逻辑。
其他回答
这是一个相当老的问题,但我也在寻找同样的答案,这就是我所发现的。
对于状态模式,让我们考虑一个中间播放器播放按钮的例子。当我们开始播放时,它开始播放,并让上下文意识到它正在播放。每次客户端想要执行播放操作时,他都会检查播放器的当前状态。现在客户端知道对象的状态是通过上下文对象播放的,所以他调用暂停状态对象的动作方法。客户端实现状态的部分以及它需要在什么状态上执行操作的部分可以被自动化。
https://www.youtube.com/watch?v=e45RMc76884 https://www.tutorialspoint.com/design_pattern/state_pattern.htm
在策略模式的情况下,类图的安排与状态模式相同。客户来此安排做一些操作。也就是说,不同的算法取代了不同的状态,比如需要对模式进行不同的分析。在这里,客户端告诉上下文它想做什么,用什么算法(业务定义的自定义算法),然后执行。
https://www.tutorialspoint.com/design_pattern/strategy_pattern.htm
两者都实现了开闭原则,因此开发人员可以向状态模式和新算法中添加新的状态。
但不同之处在于它们使用的是基于对象状态执行不同逻辑的状态模式。在战略的案例中有不同的逻辑。
老实说,这两种模式在实践中非常相似,它们之间的定义差异往往取决于你问谁。一些流行的选择是:
状态存储对包含它们的上下文对象的引用。战略则不然。 状态可以替换自己(IE:将上下文对象的状态更改为其他状态),而策略则不能。 策略作为参数传递给上下文对象,而状态由上下文对象本身创建。 策略只处理一个特定的任务,而状态为上下文对象所做的所有(或几乎所有)事情提供底层实现。
一个“经典”的实现将匹配列表中的每个道具的状态或策略,但你也会遇到混合了两者的情况。具体是国家层面的还是战略层面的,最终是一个主观问题。
当一个特定的任务有多个算法,而客户端决定在运行时使用的实际实现时,使用策略模式。
来自wiki策略模式文章的UML图:
主要特点:
这是一种行为模式。 它是基于委派的。 它通过修改方法行为来改变对象的内容。 它用来在一系列算法之间切换。 它在运行时改变对象的行为。
参考这篇文章获得更多信息和现实世界的例子:
策略模式的真实例子
状态模式允许对象在其内部状态改变时改变其行为
来自wiki状态模式文章的UML图:
如果我们必须根据对象的状态来改变它的行为,我们可以在object中有一个状态变量,并使用If -else条件块来根据状态执行不同的操作。状态模式用于通过上下文和状态实现提供一种系统的、损失耦合的方式来实现这一点。
有关更多细节,请参阅这篇journaldev文章。
与资源制作和期刊开发文章的主要区别:
The difference between State and Strategy lies with binding time. The Strategy is a bind-once pattern, whereas State is more dynamic. The difference between State and Strategy is in the intent. With Strategy, the choice of algorithm is fairly stable. With State, a change in the state of the "context" object causes it to select from its "palette" of Strategy objects. Context contains state as instance variable and there can be multiple tasks whose implementation can be dependent on the state whereas in strategy pattern strategy is passed as argument to the method and context object doesn’t have any variable to store it.
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.
在我看来,主要的区别在于他们的意图。从技术上讲,国家和战略模式看起来非常相似。 主要区别在于:
State模式在需要时更改上下文的状态,并且状态可以多次更改。context改变它的状态或者状态可以设置另一个状态 战略模式决定战略,战略很少会改变,而环境不会改变战略。
策略模式。
我们抽象出一些合理的策略:
public interface ISound
{
void Make();
}
及其具体策略:
public class DogSoundStrategy : ISound
{
public void Make()
{
Console.WriteLine("Bar");
}
}
public class CatSoundStrategy : ISound
{
public void Make()
{
Console.WriteLine("Meow");
}
}
这是对能发声的Animal的抽象描述:
public abstract class Animal
{
public void MakeSound(ISound sound)
{
sound.Make();
}
}
具体的动物是这样的:
public class Dog : Animal
{
}
public class Cat : Animal
{
}
然后我们可以像这样调用上面的代码:
Dog dog = new Dog();
dog.MakeSound(new DogSoundStrategy()); // there is a small chance
// that you want to change your strategy
Cat cat = new Cat();
cat.MakeSound(new CatSoundStrategy()); // there is a small chance
// that you want to change your strategy
有一个小的机会,你想要改变你的策略。
状态模式
想象一下,你有一个电脑游戏,英雄可以是世界上任何一个超级人物。让我们称他为英雄。他能跑、能游、能飞,还能变成钢铁侠或蜘蛛侠。你有一个按钮,你可以改变它的形状或状态为钢铁侠或蜘蛛侠。
英雄的代码是这样的:
public class Hero
{
IState _state;
public Hero()
{
_state = new SpiderManState();
}
public void Run()
{
_state.Run();
}
public void Swim()
{
_state.Swim();
}
public void Fly()
{
_state.Fly();
}
public void ChangeShape()
{
_state = _state.SetShape();
}
}
IState的接口看起来像这样:
public interface IState
{
void Run();
void Swim();
void Fly();
IState SetShape();
}
具体的状态是这样的:
public class SpiderManState : IState
{
public void Fly()
{
Console.WriteLine("Spiderman is flying");
}
public void Run()
{
Console.WriteLine("Spiderman is running");
}
public void Swim()
{
Console.WriteLine("Spiderman is swimming");
}
public IState SetShape()
{
return new IronManState();
}
}
IronManState会是这样的:
public class IronManState : IState
{
public void Fly()
{
Console.WriteLine("IronMan is flying");
}
public void Run()
{
Console.WriteLine("IronMan is running");
}
public void Swim()
{
Console.WriteLine("IronMan is swimming");
}
public IState SetShape()
{
return new SpiderManState();
}
}
现在通过点击英雄类的ChangeShape()按钮,你将能够改变英雄的状态, 例:从蜘蛛侠到钢铁侠。
因此,上下文状态(英雄)取决于并可以通过其按钮ChangeShape进行更改。这种情况会发生很多次。
您很有可能希望更改上下文的状态。
状态模式也可以被认为是替代类中许多if - else语句的一种选择。