开闭原则简介

开闭原则，即OCP（Open-Close Principle）

其定义如下：

  • 一个类应该对拓展开放，对修改关闭

当一个结构或者系统成型之后，除非遇到一些Bug或者一些软件缺陷，就不应该对系统或结构中的类进行修改，这就是对修改关闭。如果需要增加一些功能，或者扩展一些功能时，这个系统或结构应该通过扩展的方式来增加或扩展一些功能，这就是对扩展开放。

命令模式与开闭原则

这是因为，在经典的命令模式中，有关闭修改的部分，也有开放扩展的部分。

经典命令中的几个角色：

  • Invoker
  • Receiver
  • Command
  • ConcreteCommand

其中的ConcreteCommand是我们可以不断扩展的部分，也就是整个命令系统中，ConcreteCommand是开放出来的扩展，而Command是扩展的标准。

而在系统成型时，Invoker则是不推荐修改的部分，Receiver也许会根据Command的扩展为自己增加一些方法，或者增加Receiver的实现类型，所以也算是开放出来的扩展，但是Receiver的内部代码是不推荐修改的，所以也有对修改关闭的部分。

总结如下：

  • Invoker：关闭修改（Architecture）
  • Receiver：关闭内部修改，开放实现与方法扩展（在决定版框架中，我们的Receiver是System、Model这些，都是直接可以改的）
  • Command：扩展的标准（继承ICommand，实现特定的新Command接口）
  • ConcreteCommand：开放实现的扩展（继承新接口，实现新拓展）

如果要真正实现命令模式，一般会把命令模式实现成为一个系统，比如像一些行为树的核心是命令模式。

决定版架构中的Command，并不是在一个系统中，而是把经典命令模式中的几个角色融入到架构中，形成了一套支持命令的架构，这个时候，也是遵循了开闭原则的。如果想实现一套命令队列、复原等功能，和经典命令模式一样，直接写在Invoker（Architecture）内部即可。

对于开闭原则的定义其实有一些细节不同的定义，有的时候开闭原则会说成如下：

  • 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

而本篇的定义则是：一个类应该对扩展开放，对修改关闭。

实际上更确切地说，从一个系统或一个结构去定义开闭原则更好一些。

  • 一个系统应该对扩展开放，对修改关闭。

都是说的通的，只不过都太宏观了，所以这里用类这个角度。