设计原则利剑六--开闭原则

英文名称：Open Closed Principle(OCP)

中文名称：开闭原则

作      用：开闭原则与前面几个原则不一样，这个属于是精神层面的原则，其目的就是告诉我们要拥抱变化，如何在考虑未来变化的同时来

               设计好自己的项目，以及在变化发生的时候，如何来规避风险，使得变更带来的影响最小化。一个遵循开闭原则建造的项目，很定

               在业务粒度上的划分很定是很合理，会提高其复用性以及可维护性

核心之处：一个软件实体如类、模块和函数应该对扩展开发，对修改关闭，其告诉了我们要用积极的心态去拥抱需求，并告诉了我们解决新

               需求的方案

理      解：对于设计好的类、模块与函数，未来如果有变更，那么要用扩展的方式来解决，而不是去修改代码来解决，我忽然到目前为止对待

               需求变更的方式都是修改代码，要知道此次修改了代码，下次仍然会修改代码，何不设计一个好点的模式呢？

理论实践：

              用一个书店售书来举例子，正常设计的售书上线以后，忽然有个需求说100元以上的书是8折扣，100元以下的书是8折，那么最后的到的用户价格很定会发生变化，那么我们该如何来拥抱这一变化呢？去修改以前的类的源代码很定时不合理的，因为今天打折，明天可能又会不打折，那么利用开闭原则的指导，对于此种变更，应该通过实现一个新的抽象类来解决。以前的设计模式上UML图如下：

               那么既然有了新的需求，那就需要来修改设计，新的设计模式如下：

            看到这种解决方案后，忽然心中对需求的不断变化充满了信息和渴望，因为有了好的解决方案，渴望的是看自己遇到了真是的需求变更自己如何使用这一原则来处理问题。那么如果问题继续进一步的改进，公司忽然要加入计算机书籍的销售，而且计算机书籍还拥有自己的属性，那么设计如下：

       一旦这个系统是遵循此六种原则来设计的，基本上能够经受得住一般的需求变动。

       同样也想到了自己现在项目的设计，其中有一个需求的变动就是登录用户的变动，刚开始做项目的时候说只有销售、销售总监以及普通用户，后来又增加了4A销售，4A销售总监的角色，而每个不同的角色所看到的销售总监以及销售下拉列表类看到的数据会是不一样的，所以在销售总监类以及销售类中写了很臃肿的代码，每增加一个角色，我就得修改一次，修改完毕还得去测试。包括这个用户类型叠加起来，如何处理还未想到一个很好的解决方案，此时先放在这里，等待今后的解决。

      忽然想到了一个好点的设计方案，根据“将变化分装到不同的接口中”指导思想，将销售总监以及销售相关的属性分离出来，如：团队编号，用户编码，上级用户分离出来，从此任何一个用户添加为销售角色，只要在此表中存在，那么就会在下拉框中选择到该用户，能添加客户以及下订单。这样就保证了UserInfo类的不变动行，而对于总监能带领多个城市的销售功能，则根据其负责的城市来得到销售列表。