界定类和模块边界及通信的原则_单一职责原则和迪米特法则
界定类和模块边界及通信的原则
前言
前面分两个文章四个面向对你的原则，其中有一个是设计的基本原则，还有两个是在基本原则下我们应该如何去考虑扩展和拥抱变化的原则，那么前面四个原则还缺少点啥，就是这次我想写的，前面都讲了面向对象要开闭，类要符合里氏代换，要接口隔离，要依赖倒置，但是如何让每个类和模块的边界的确认方式，在抽象过程中应该基于的原则，好像没有方法论的指导，个人认为单一职责原则和迪米特法则就是阐述如何去解决这两个问题的原则，解决类或者对象的耦合问题。接下来容我具体的道出个一二。
单一职责原则（SRP）
https://baike.baidu.com/item/%E5%8D%95%E4%B8%80%E8%81%8C%E8%B4%A3%E5%8E%9F%E5%88%99
单一职责原则说的是类和模块应该承担起他应该有的职能，而不是承担他那些不必要的职责，防止职责的扩散，程序员在开发过程中都知道要高内聚，遵守单一职责的类就是高内聚的，但是为什么在编写代码中会出现职责扩散的情况，个人认为存在下面两个误区并解释一下。
- 在心里没有单一职责的意识，培训和学习过程中大家觉得功能实现最为重要，而且一在的强调将不同的功能拆分成不同的方法，方便修改，导致在开发过程中当一个类的代码过长时，只是意识到这个类的方法是不是太复杂，应该拆出来，而不是站在更高层的去问题，是不是职责分配的有问题，应该拆分到其它的类里。
- 现在的框架大部分都是按接口实现注入的，导致我们程序员觉得一个接口就一个实现，有时候觉得这好像就是单一职责的原则，我觉得这个很片面，我觉得单一职责原则类的职责单一也是一个方面，在接口隔离的原则上，如何保证接口则的单一也是单一职责的体现，接口职责的单一体现在接口表达的角色是单一的，他拥有的功能是单一的，最简单的盒子，在审批流程中，其实申请接口是一个角色，他只负责收集申请这个岗位的功能而不能把审核的方法加到其中，而且他会有很多种实现，如柜台，网络等等，其实这都是单一职责的体现。
迪米特法则（LKP）
https://baike.baidu.com/item/%E8%BF%AA%E7%B1%B3%E7%89%B9%E6%B3%95%E5%88%99
有时候大家总是说你有知道的太多了，那么迪米特法则就是不让你知道的太多的意思，也就是最小知识原则，一个对象应该知道别人最少的事情，也不要让别人知道你太多的事情，这样的类最为单纯，耦合也就最小。
前面单一职责原则定义了类应该如何界定边界和方法的定义的原则，那么迪米特法则就定义对象应该如何和其它对象通信，获取其它对象或者模块知识的准则，就是说尽可能不要知道别的对象太多的东西，同时对于本身对象来说，也只要知道自己职责相关的知识就好。那么他应该分三个方面
- 本身类他拥有的信息应该是和他相关的，不必要知道他不应该知道的信息
- 与其它模块和类通信时，应该尽量少，如果要有那也应该释放出自己最窄的信息。
- 成员变量应该尽可能设计好让别的类访问，只释放出最窄的可以让其它类访问的变量。