Does the command pattern uses OCP ?
In a command patter the invoker is only extensible by actually extending the class. If we want to add custom methods to it, we can make our own sub-class or we could modify the base class's constructor, which violates the open/closed principle.
Which leads me to the question, is the command pattern using OCP or not
The one-liner definition of OCP is very nice, although it tends to mislead.
Quoting the original Bob Martin's article on OCP:
It should be clear that no significant program can be 100% closed. ... In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed.
(I really recommend you reading the whole paper and also Jon Skeet's critique)
So basically, OCP is more about finding the right design balance to be able to add a new functionality while breaking the least stuff possible, e.g. be able to extend and not have to modify the codebase thoroughly.
Therefore, it's more about upholding existing interfaces and contracts while modifying existing code.
Whether a command pattern breaks OCP is based more on where and how it is used than the pattern itself. And since you provided no context of usage, your question is not really answerable.
If we encounter a case when our design, that uses some specific pattern, cannot accommodate a new requirement without some modifications, it won't mean that the pattern (doesn't matter which one) is bad and violates some good design principles.
It will mean only that our design is not prepared to gracefully handle such cases.
In some cases yes. But more than often it is a sign of either of the:
You may and should consider your design carefully, but no matter how adaptive your system is, once upon a time either requirements will change or some piece of obscure domain knowledge will force you to change even the most well-designed system.
Probably not. You can't design system that can be extended in any possible way without compromising other good design principles. Because such systems will usually sacrifice performance and(or) ease of understanding.
It is a guilty fun to read about similar overly adaptive systems on thedailywtf, but you don't want to end up maintaining one.
If such changes will be made without any considerations about bigger design, then probably yes. But if you apply such changes with proper commitment to reconsidering and, possibly, refactoring them during the consolidation phase then you will be able to hold the entropy in check.
So, does the Command pattern violate the Open-Closed principle?
No. In most cases it is the system's requirements that make specific usage of this pattern not as open-closed as we'd liked it to be.
Openness towards change is a strategic decision. That means it is up to designer to choose against which changes the code will be open and against which it will not. Also, quite often, making design open against one change will make it harder to make it open against another.
Command pattern makes the the design open against change of adding new behavior with each behavior being usable in one context (eg. common setup or teardown of behaviors). It is not open against changing existing commands (unless decorator can be applied) and against changes to how the command is setup.
If you find you want make design open against those changes, you should either extend the design or scrap the design and start again with the new requirements.
