一：单一职责原则

        类的单一职责这个很好理解，就是一个类只负责一件事儿，只实现一个相关功能 

        比如：类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的耦合

 我觉得没有所谓的完全迪米特，只是我设计程序在一定程度上遵守这些规范，

会提高程序的扩展和降低后期改动的引起的连锁反应(耦合引起)