SRP 单一职责原则
SRP：单一职责，这个原则是最容易被理解为：“每个模块都应该只做一件事”。其实这只是底层实现细节的设计原则，不是单一职责的全部。<br>例如有一个员工类：他有两个方法，方法1销售部门制定的，方法2人力资源部门制定的。这两个方法开始时用到了共同的计算工作时长的方法，但是销售部门是看销售业绩的，后来销售部就修改了计算工作时长的方法（只要完成当天业绩就为考勤合格），结果到月底的时候，人力资源部进行汇报时，只有销售的工作时长正确，其他工种的员工即使是没有迟到早退也是考勤异常的。上述案例每个方法都是单一功能。但是不同的行为的代码依赖了同一个方法导致问题发生。这个时候我们就需要定义一个销售类，一个人力资源类，分别实现员工类中自己定制的方法，此时需要修改工作时长方法时，就在各自的类中提供对应的工作时长方法即可。这样就解决了上面使用同一个代码导致其他业务出现问题的情况。<br><br> 结合上面案例，单一职责，描述应该是：每个模块应该只对某一类行为负责。
OCP 开闭原则
OCP：开闭原则，一个好的架构设计应该是不修改的前提下容易进行扩展。<br>大屏需要展示今日数据，运营后台需要看今日报表数据，同样的数据展示形式不同，service只负责生产当日数据，具体展示规则由不同的service实现各自的业务逻辑和处理规则。若此时，财务也要出当日的财务报表，那我们可以再增加一个财务报表的service，然后根据service生产的当日数据按照财务规则进行生成报表即可。这个案例很好的展示了不修改的情况下进行扩展<br>
ISP 接口隔离原则
不用的用户行为要是用不用的接口进行声明，使用不用的接口实现，不能在同一个类中进行多种操作。
注意
系统A设计时依赖于框架Q，而Q框架的本身又依赖于一个特定的存储C，而C中有一些功能时Q中不需要的，我们对这些不需要的功能进行了修改，导致需要框架Q重新编译部署。Q的重新部署导致系统A的重新部署，若是此时C中的一个无关的功能导致Q和A的运行出问题，那就很糟糕了。<br><br>所以我们在做设计时所有不需要的东西都不应该存在依赖关系。这样不必要的依赖关系可能会带来意料之外的麻烦。
