战略设计模式和国家设计模式之间的区别是什么?我在网上浏览了不少文章,但看不出明显的区别。
有人能用外行的语言解释一下吗?
战略设计模式和国家设计模式之间的区别是什么?我在网上浏览了不少文章,但看不出明显的区别。
有人能用外行的语言解释一下吗?
当前回答
在我看来,主要的区别在于他们的意图。从技术上讲,国家和战略模式看起来非常相似。 主要区别在于:
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语句的一种选择。
其他回答
不同之处在于它们解决的问题不同:
State模式处理对象(处于)什么(状态或类型)——它封装了依赖状态的行为,而 策略模式处理对象如何执行特定任务——它封装了一个算法。
然而,实现这些不同目标的结构非常相似;这两种模式都是带有委托的组合示例。
关于它们的优点:
通过使用State模式,状态保持(上下文)类不再知道它是什么状态或类型以及可用的状态或类型。这意味着类遵循开闭设计原则(OCP):类对状态/类型的更改是关闭的,但是状态/类型对扩展是开放的。
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.
在我看来,主要的区别在于他们的意图。从技术上讲,国家和战略模式看起来非常相似。 主要区别在于:
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语句的一种选择。
这两种模式都用于改变对象的行为,
按照设计,状态模式对象只有一个状态,对象的行为基于实现的单个状态(类)及其子类。
相反,策略没有单一的状态,对象的行为是由不同策略对象的实现决定的。
老实说,这两种模式在实践中非常相似,它们之间的定义差异往往取决于你问谁。一些流行的选择是:
状态存储对包含它们的上下文对象的引用。战略则不然。 状态可以替换自己(IE:将上下文对象的状态更改为其他状态),而策略则不能。 策略作为参数传递给上下文对象,而状态由上下文对象本身创建。 策略只处理一个特定的任务,而状态为上下文对象所做的所有(或几乎所有)事情提供底层实现。
一个“经典”的实现将匹配列表中的每个道具的状态或策略,但你也会遇到混合了两者的情况。具体是国家层面的还是战略层面的,最终是一个主观问题。
当你有一个可以分为两个任务的项目时:
任务1:您可以使用两种不同的算法之一来完成:alg1, alg2
任务2:您可以使用三种不同的算法之一来完成:alg3, alg4, alg5
Alg1和alg2是可互换的;Alg3、alg4和alg5是可以互换的。
在任务1和任务2中选择哪种算法取决于状态:
状态1:任务1中需要alg1,任务2中需要alg3
状态2:任务1中需要alg2,任务2中需要alg5
上下文可以将状态对象从状态1更改为状态2。然后,您的任务将由alg2和alg5完成,而不是alg1和alg3。
您可以为任务1或任务2添加更多可互换的算法。这就是战略模式。
你可以在任务1和任务2中使用不同的算法组合获得更多的状态。状态模式允许从一种状态切换到另一种状态,并执行不同的算法组合。