迪米特是触摸架构的开始(我瞎说的)

迪米特是触摸架构的开始(我瞎说的)

为什么这么说呢？因为：解耦解耦解耦啊（重要的事情说三遍）。额……解耦急速架构了？不不不，我可没这么说，触摸架构嘛！

====================

迪米特法则：最少知识法则，一个对象应该对其他对象有最少的理解。

说是这样说，其实真正用起来还是别别扭扭。

我们换个角度讲：

一个良好的架构，模块与模块之间、层与层之间完全像是一个黑盒子连着一个黑盒子。模块与模块只关心输入与输出结果，至于中间过程，是毫不在意的。

而这样的架构，有一个更洋气的叫法：TTD - 测试驱动开发。

虽然这样的开发模式有点理想主义（但比起后面我们要讲的开闭原则来说，已经比较现实了），但依然是我们应该持之以恒追求的。

那如何追求这样的理想主义呢？保证你的代码可测试！

如何保证可测试？有着明确的输入输出！

什么是不可测试？一个耦合了其他模块功能的东西，因为不确定的输入输出当然就是不可测试的了。

所以问题回来啦，解耦解耦解耦！！！

那如何实现迪米特呢？解耦解耦解耦！！！！

那怎么解耦呢？保持单一，嘿嘿，这个时候你就应该回头看看单一原则了。

迪米特实现

比起单一原则，迪米特更注重类、模块。而类的单一我们之前说过了，这个要看情况，同样，模块也要看情况。

这是一个经验类型的东西，而现在，只能告诫你一句书中的话：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中。

迪米特我能说的不多了，因为自己本身对这个原则的理解也并不是那么透彻。