战略设计模式和国家设计模式之间的区别是什么?我在网上浏览了不少文章,但看不出明显的区别。
有人能用外行的语言解释一下吗?
战略设计模式和国家设计模式之间的区别是什么?我在网上浏览了不少文章,但看不出明显的区别。
有人能用外行的语言解释一下吗?
当前回答
策略:策略是固定的,通常由几个步骤组成。(排序只构成了一个步骤,因此是一个非常糟糕的例子,因为它太原始了,无法理解此模式的目的)。 策略中的“主”例程调用了一些抽象方法。如。“进入房间策略”,“main-method”是goThroughDoor(),它看起来像:approachDoor(), if (locked()) openLock();openDoor ();enterRoom ();把();closeDoor ();if (wasLocked()) lockDoor();
现在,这个通用“算法”的子类可以实现该算法的步骤,该算法用于通过可能锁着的门从一个房间移动到另一个房间。
换句话说,策略子类化不会改变基本算法,只会改变单个步骤。
上面是一个模板方法模式。现在把属于一起的步骤(解锁/锁定和打开/关闭)放到它们自己的实现对象中,并委托给它们。例如,带钥匙的锁和带码卡的锁是两种锁。将策略委托给“Step”对象。现在您有了一个策略模式。
状态模式是完全不同的东西。
你有一个包装对象和被包装的对象。被包装的是“状态”。状态对象只能通过它的包装器访问。现在您可以随时更改包装对象,因此包装器似乎可以更改其状态,甚至更改其“类”或类型。
E.g. you have a log on service. It accepts a username and a password. It only has one method: logon(String userName, String passwdHash). Instead of deciding for itself whether a log on is accepted or not, it delegates the decision to a state object. That state object usually just checks if the user/pass combination is valid and performs a log on. But now you can exchange the "Checker" by one that only lets priviledged users log on (during maintanace time e.g.) or by one that lets no one log on. That means the "checker" expresses the "log on status" of the system.
最重要的区别是:当你选择了一种策略,你要坚持它,直到你完成它。这意味着你调用它的“主方法”,只要它在运行,你就永远不会改变策略。OTOH在系统运行时的状态模式情况下,您可以随意更改您认为合适的状态。
其他回答
有人能用外行的话解释一下吗?
设计模式并不是真正的“门外汉”概念,但我将尽量使其清楚。任何设计模式都可以从三个维度来考虑:
模式解决的问题; 模式的静态结构(类图); 模式的动态(序列图)。
让我们比较国家和战略。
模式解决的问题
State有两种用法[GoF book p. 306]:
An object's behavior depends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.
如果您希望确保您确实存在状态模式解决的问题,那么您应该能够使用有限状态机对对象的状态进行建模。你可以在这里找到一个应用的例子。
每个状态转换都是state接口中的一个方法。这意味着对于设计来说,在应用此模式之前必须非常确定状态转换。否则,如果您添加或删除转换,则需要更改接口和实现它的所有类。
我个人认为这种模式并不有用。您总是可以使用查找表实现有限状态机(这不是面向对象的方法,但它工作得非常好)。
策略用于以下[GoF书第316页]:
many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors. you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms [HO87]. an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures. a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.
在哪里应用Strategy的最后一种情况与称为用多态性替换条件的重构有关。
总结:国家和战略解决的问题完全不同。如果您的问题不能用有限状态机建模,那么可能的状态模式就不合适。如果您的问题不是关于封装复杂算法的变体,那么Strategy就不适用。
模式的静态结构
State具有以下UML类结构:
Strategy具有以下UML类结构:
总结:就静态结构而言,这两种模式基本相同。事实上,像这样的模式检测工具认为“的结构 […]模式是相同的,禁止他们 通过自动过程进行区分(例如,不引用 到概念信息)。”
但是,如果ConcreteStates自己决定状态转换(参见上图中的“可能决定”关联),那么就会有很大的不同。这导致了具体状态之间的耦合。例如(请参阅下一节),状态A决定到状态b的转换。如果Context类决定到下一个具体状态的转换,这些依赖关系就消失了。
模式的动态性
正如上面的Problem部分所提到的,State意味着行为在运行时根据对象的某些状态而改变。因此,状态转换的概念适用于有限状态机的关系。[GoF]提到转换可以定义在ConcreteState子类中,也可以定义在一个集中的位置(比如基于表的位置)。
让我们假设一个简单的有限状态机:
假设子类决定状态转换(通过返回下一个状态对象),动态看起来像这样:
为了展示《战略》的动态,我们可以借用一个真实的例子。
Summary: Each pattern uses a polymorphic call to do something depending on the context. In the State pattern, the polymorphic call (transition) often causes a change in the next state. In the Strategy pattern, the polymorphic call does not typically change the context (e.g., paying by credit card once doesn't imply you'll pay by PayPal the next time). Again, the State pattern's dynamics are determined by its corresponding fininte state machine, which (to me) is essential to correct application of this pattern.
In Strategy pattern while implementing searching , we can have multiple strategies of searching e.g NaiveStrategy(), KMPStrategy() or RabinKarp() Strategy. These are all independent and there are somewhat stable choices. And most important, strategies can't shift from one another. Only Context is able to change strategies. State Pattern on the other hand is based on concept of Finite-State Machines. The states can transition from one another. Here states are less stable as compared to the strategies. And one thing, each concrete state maintains a reference to context and hence is able to transition to another state.
因此,关键在于在策略中,只有上下文可以设置策略,而在状态模式下,状态可以转换到其他状态。在策略模式中,策略彼此不知道。而在状态模式中,状态并不是不知道彼此,并且在它们维护对上下文对象的引用时允许转换。
“策略使这些对象完全独立,彼此不知道。然而,State不限制具体状态之间的依赖关系,允许它们随意改变上下文的状态。”
参考资料:https://refactoring.guru/design-patterns/strategy
“策略”只是一种算法,你可以根据自己的需要在不同的情况下改变它,它为你处理一些事情。 例如,你可以选择如何压缩一个文件。Zip or rar…在一个方法中。
但是“状态”可以改变你所有的对象行为,当它改变时, 甚至它也能改变其他领域……这就是为什么它有一个指向它的主人的引用。您应该注意到,改变对象字段完全可以改变对象行为。 例如,当你在obj中将stat0更改为State1时,你将一个整数更改为10。因此,当我们调用obj.f0()进行一些计算并使用该整数时,它会影响结果。
战略模式和状态模式具有相同的结构。如果您查看两种模式的UML类图,它们看起来完全相同,但是它们的意图完全不同。状态设计模式用于定义和管理对象的状态,而策略模式用于定义一组可互换的算法,并让客户选择其中之一。因此,策略模式是客户端驱动的模式,而对象可以管理自己的状态。
简而言之,使用策略模式,我们可以动态地设置一些行为,使用状态模式,我们可以确定,对象将随着状态的变化而在内部改变其行为。