设计模式六大原则--迪米特法则

背景

在学校学习时，可能因为某些事你得去其他二级学院的老师帮忙，大部分老师都是忙的（也许是的）很可能一件小事你要跑很多次。但是如果你这件事直接找的是其他学院的院长，并且院长同意帮忙的话这件事解决起来就容易多了。不知怎地最近老是瞎想感觉这件事又能和设计模式中的迪米特法则（Law of Demeter，LOD），也叫最少知识原则（Least Knowledge Principle，LKP）扯上关系，接下来就由小生带大家粗略的了解一下这个法则吧。

定义

如果两个类不必批次直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

详细说明

迪米特法则首相强调的前提是在列的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说一个列包装好自己的private状态，不需要让别人的类知道的字段或行为就不要公开。

迪米特法则其根本思想是强调类之间的松耦合。我们在程序设计时，类之间的耦合越弱，也有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说隐藏信息促进了代码的复用。

如果两个类不必彼此直接通信，那么就不要让这两个类发生直接的相互作用。具体做法就是引入一个外观对象，它为子系统提供了一个单一而简单的屏障从而使子系统间的通信和相互依赖关系达到最小。

示例（设计模式中的外观（门面）模式）

//客户端代码
    class Program
    {
        static void Main(string[] args)
        {
            Facade facade = new Facade();
            facade.MethodA();
            facade.MethodB();
            Console.Read();
        }
    }
    //类似的代码可以建立多个系统子方法
    class SubSystemOne
    {
        public void MethodOne()
        {
            //...方法一
        }
    }  
    class Facade
    {
        SubSystemOne one;     //可以有多个子系统
        public Facade()
        {
            one = new SubSystemOne();
            //...
        }
        public void MethodA()
        {
            Console.WriteLine("\n方法组A() --- ");
            one.MethodOne();
            //...
        }
        public void MethodB()
        {
            Console.WriteLine("\n方法组B() --- ");
            two.MethodTwo();
            //...
        }
    }

优劣

优点

总结成一句话就是降低了类之间的耦合，减少了类之间不必要的依赖。

缺点

系统里造出大量的小方法，这些方法仅仅是传递间的调用，与系统的商务逻辑无关。遵循类之间的迪米特法则是一个系统的局部设计的简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。