一:单一职责原则
类的单一职责这个很好理解,就是一个类只负责一件事儿,只实现一个相关功能
比如:类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的耦合
我觉得没有所谓的完全迪米特,只是我设计程序在一定程度上遵守这些规范,
会提高程序的扩展和降低后期改动的引起的连锁反应(耦合引起)
网友评论