Ah, an old-fashioned game needs one of these patterns? So.
The main difference is that the strategy pattern is isolated, indicates a rule to be applied according to an external implementation at some specific point, and can parameterize any desired behavior in the object. And the standard of the specification is something more complex and establishes a set of rules, usually chained, that will be applied somewhere, and each individual rule can be changed, added or removed, as well as changing the order, and these rules should be mainly validations (in a broad sense, and not just traditional validation, can be a selection for example), so much more limited. Therefore there should be no confusion, they serve very different purposes. Generally the question about using Strategy is whether it would not be better to Bridge, Adapter, State, Template Method, Decorator, and sometimes Visitor or Facade.
I already have my doubts if I should use one of them, but the Specification seems less interesting there, although I could be wrong for not knowing the details. The more you apply these things you tend to adopt the antipattern called Second System. On the other hand, if you want to insist on it, you might want to use it as an "AI" mechanism, and it might make sense since you want to complicate the solution, using this pattern to chain decisions. Remember he’s only one if
much more complicated, is OOP being used where the simple imperative solved the problem. And if it varies what to do in certain sequences then Strategy may be useful, but I don’t think that’s even the case, think about others I mentioned above. I can’t think for not having details.
Note that C# has mechanisms that often make a certain pattern unnecessary. That’s why I always say: People want to use Patterns design without even knowing what it means, it’s just because it’s fashionable.
Design Patterns are bug Reports Against your Programming language
-- Peter Norvig
Thank you so much for your help!!
– luturol