使用函数的得墨忒耳法则来解耦

编写“羞怯”的代码：

包含两层意思，一个是不向别人暴露你自己，不会没必要的向其他模块暴露任何事情；另一个是不与太多人打交道，不依赖于其他模块实现的模块。

不与太多人打交道，说的就是要降低与别人的耦合，比如你的模块A依赖于一个模块B的功能，那么你就仅仅调用这个模块B的功能，而不要调用这个模块的实现中出现的模块C的功能，因为，一旦B的模块实现方式改变，那么C可能不存在，或者C出现了变动，那么它的影响就不仅仅是B，还有A也受到了影响。而如果A只调用B，则即使B的实现去掉了C模块，那么只要B的接口不变，那么A是不受影响的，或者如果C变了，那么由于A只调用B，则C的变动影响的只会是B，而不会影响A。因此，耦合性强的系统，改变代码将会变得非常困难，牵一发而动全身。

函数的得墨忒耳法则试图使任何给定程序中的模块之间的耦合减至最少，它设法阻止你为了获得对第三个对象的方法的访问而进入某个对象。

法则规定：某个对象的任何方法都应该只调用属于以下情况的方法：

1.这个对象自己拥有的方法；

2.传入该方法的参数的方法；

3.该方法创建的对象的方法；

4.该对象直接拥有的对象的方法；

代码如下：

 class A{ 
        private B b = new B();
        private void methodE(){} 
        public void methodA(C c){
                D d = new D(); 
                methodE(); //1这个对象自己拥有的方法，可调用 
               c.print(); //2传入该方法的参数的方法，可调用 
               d.invert(); //3该方法创建的对象的方法，可调用 
               b.kill(); //4该对象直接拥有的对象的方法，可调用 
               F f = b.getF(); 
               f.rock(); //5 该对象依赖对象的实现的模块，不可调用。 
         }
}

 当然，得墨忒耳定律中，由于不建议调用依赖模块B的实现的模块C，因此，你不得不编写大量的包装方法，这些方法只是把请求转发给被委托者。存在运行时代价和空间开销，如果你很在乎这些，那么你不得不在性能和可维护性灵活性之间做个平衡，比如为了性能而使某些模块紧密耦合。呵呵，有时为了性能不得不‘反规范化’，就像在数据库设计中，为了提高访问速度，避免联合查询，而对某些字段采用冗余一样。

附件：维基百科对“得墨忒耳定律”的解释

得墨忒耳定律（Law of Demeter，缩写LoD）也叫做“最少知识原则”，是一种开发软件的设计原理，特别是面向对象的程序设计，得墨忒耳定律是松耦合的一种特殊情况。该指导原则是1987年末在美国东北大学发明的，该原则可以简单地概括为以下方式之一：

1每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；

2每个单元只能和它的朋友交谈：不能和陌生单元交谈；

3只和自己直接的朋友交谈。 这个原理的名称来源于希腊神话中的农业女神，孤独的得墨忒耳。

ps: Law of Demeter, 中文翻译 迪米特 或者 得墨忒耳 法则，貌似翻译为前者的比较多，但是程序员修炼之道中翻译为后者。

参考资料：

1 《程序员修炼之道》

2   维基百科