一：单一职责原则
类的单一职责这个很好理解，就是一个类只负责一件事儿，只实现一个相关功能
比如：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
说白了如果一个类负责的东西多了，代码不好看，也不好维护，万一你接手别人的老代码，不熟悉业务或者是全部代码的的情况下，把某些类改造了，万一类中有隐藏逻辑就会很容易产生未知的故障。
尽量遵循单一原则，但是也要根据实际情况，实在不行也要保持类中的职责和方法间的独立。
二：迪米特原则
一个类对自己依赖的类知道的越少越好
A：不需要别人知道的就private，提供给别人使用或者需要别人提供参数等的用public
B：不管类的内部逻辑多复杂但都尽量封装在自己内部，只对外提供访问接口或者方法
C：只与自己的朋友通讯，如果两个类不必彼此直接通信，那么这两个类就不应该发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
举个android开发的mvp模式的例子来说明迪米特原则
model 负责数据 view 负责界面显示 presenter 负责业务逻辑
违反迪米特原则的：
我们平时开发安卓如果是个人开发 绝对大部分m 和 p都会在 v中出现，有时候我们会把获取数据m干的事儿直接在v中干，有时候把复杂业务逻辑放到p中去干
正确的是 v只管和p通讯，m只和p通讯，这样降低m和v的耦合
我觉得没有所谓的完全迪米特，只是我设计程序在一定程度上遵守这些规范，
会提高程序的扩展和降低后期改动的引起的连锁反应(耦合引起)
