SOLID软件设计原则之OCP原则

本文链接：https://blog.csdn.net/DeliaPu/article/details/105601365

年前匆匆整理了一下SRP原则，即单一职责原则：SOLID软件设计原则之SRP。趁着周末有时间，还一还之前欠下的债。

庄子《刻意》篇有云：“形劳而不休则弊，精用而不已则劳，劳则竭”。不停地忙碌容易让人陷入疲倦，忘记为何而出发，适当的闲暇才是思想的温床，也为更好地工作积蓄力量。在项目不是压迫得特别紧张的情况下，周末真的更适合学习和思考，因为有难得的独处和安静来梳理自己的思路。

言归正传。当我们还是初级开发者的时候，总是希望最好是一个软件做完了就不要再来新的变更，内心里对变化充满了抗拒。但我们在设计任何系统的时候，如果一开始就指望需求确定后就不再变化，这在现实中是不大可能的，也不科学。软件开发没有一劳永逸的事，不管我们情不情愿，以开放的心态看待变化的世界是每一个开发者应该具备的素质。

显然，一套未经良好设计的软件，面对较大需求变更的时候往往需要推倒重来，这显然需要付出相当大的成本和代价。既然需求一定会发生变化，那么怎样做设计才能在面对需求变化时，以最小的代价实现既定的目标呢？OCP原则给了我们答案。

OCP原则即Open Closed Principle, Software enities like classes, modules and functions should be open for extension but closed for modifications。也就是说，软件实体(类、模块、函数等等)应该对扩展开放，对修改关闭。

对于一个软件实体来说，绝对的对修改关闭是不可能的。无论一个模块多么“封闭”，都有可能存在一些无法与之兼容的变化。既然不可能完全封闭，设计者在设计阶段必须能够尽可能地设想出未来可能发生的变化，以及可以不变的部分，将不变的部分封闭起来，而对变化的部分，则通过构造抽象来将其隔离。

打个比方，一家小公司最初只有20个研发人员，这些研发人员采用统一的薪酬管理方法，薪酬系统里只有一种计薪模式，假如是基本工资+奖金。随着公司业务的发展，公司渐渐成立了人事部(基本工资)、销售部(底薪+提成)，等等。每一个部门的计薪方式可能有所不同，那么薪酬管理软件如何设计呢？每增加一种计薪方式就去修改原有的算法显然是低效的，而且容易影响到原本稳定的计薪方式。合理的做法是，将计薪功能抽象出来，当有新的计薪模式来的时候，只需要添加新的算法类即可，而不需要改动原有稳定的算法。合理的设计如下图。假如将来要再增加一个售后部门的计薪方式，那么只需增加一个售后薪酬算法类即可。