浅谈设计模式-迪米特法则

书接上回，本篇继续讲一下设计模式六大原则(有些书认为是7大原则)

原则定义

迪米特法则（Law of Demeter，LoD）的定义有点意思，有2种表述

1> 最少知道原则，指一个对象应当对其他对象有尽可能少的了解。

2> 只和直接的朋友交流(也有说法：不要与陌生人说话)

初看有点令人摸不着头脑，细细品品，好像是那么一回事，说下个人理解：

1> 最少知道原则，指一个对象应当对其他对象有尽可能少的了解。

其实可以理解为，在符合设计(开发)规范前提下，对象与对象间能不交互就不要交互，保持对象的独立性，降低类间耦合度，提高模块的复用性。

2>只和直接的朋友交流(也有说法：不要与陌生人说话)

这里的朋友，是朋友类的意思，理解起来有点抽象，因为我们对象朋友类这词有点陌生。迪米特法则提出者给出朋友类定义：A类如果被B类依赖，那A类就是B类的朋友类。下面都是B类的朋友类存在形式

public class A{//....
}

成员变量：

public class B{private A a;
}

方法参数：

public class B{public void someMethod(A a){...}
}

方法返回值：

public class B{public A someMethod(){return a;}
}

需要注意，这种形式存在时，A类不算是B类的朋友类，而是陌生人

方法中，A类左右局部变量/对象

public class B{public void someMethod(){A a = new A();}
}

理想状态就是这样啦，但真实操作哪有那么理想，类多之后肯定存在或多或少类间直接较互，特别是上面讲的与陌生类交互，该怎么办？迪米特法则建议通过友元类的方式类避免。这里的友元类可以理解为：中介类，也可以理解为一种统一调配的类。下面例子：

public class C{void doWork(){...}
}//A不方便直接与C交互
public class A{public void doWork(){C c = new C();c.doWork();}
}//可以借助B
public class B{public void doWork(){this.getC().doWork();}public C  getC(){return new C();}
}//改造后的A
public class A{public void doWork(B b){b.doWork();}
}

B为友元类，A借助B类实现与C类的间接交互。

案例分析

需求：乘客预约出租车去上班

//出租车
public class TaxiCar {public void run() {System.out.println("司机大叔开始达到目的地....");}
}

//司机
public class Driver {public TaxiCar getCar() {System.out.println("司机大叔按约定时间达到约定地点等待客户...");return  new TaxiCar();}
}

//乘客
public class Passenger {public void goToWork(Driver driver) {TaxiCar car = driver.getCar();car.run();}
}

测试：

//测试
public class App {public static void main(String[] args) {//客人Passenger p = new Passenger();//司机Driver driver = new Driver();//上班p.goToWork(driver);}
}

结果：
司机大叔按约定时间达到约定地点等待客户...
司机大叔开始达到目的地....

解析

上面模拟乘客上班场景，乘客预约司机，司机使用出租车送乘客上班。咋一看毛事没有啥问题，细看有点怪怪的，比如Passenger类goToWork方法，传入Driver类之后，通过Driver类的getCar方法，然后在使用TaxiCar类的run方法完成goToWork功能。这里的TaxiCar对于Passenger类是陌生类，违背了迪米特法则不与陌生人交流的要求。

改进版

修改后Drvier类

//司机
public class Driver {//私有private TaxiCar getCar() {System.out.println("司机大叔按约定时间达到约定地点等待客户...");return  new TaxiCar();}//新增驾车方法public void drive(){TaxiCar car = getCar();car.run();}
}

修改后Passenger类

//乘客
public class Passenger {public void goToWork(Driver driver) {driver.drive();}
}

解析：

改进后的案例就合理多了。Passenger类不需要在意TaxiCar类怎么操作，只需要Driver能完成driver功能即可。Driver使用drive方法遮蔽Passenger类对TaxiCar类直接引用，这符合迪米特法则。

使用注意

迪米特法则，对类之间交互的宽度与深度进行限制，正确使用可以提高系统架构复用率跟拓展性。但过度使用迪米特方法，会使用系统产生大量的友元类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时要反复权衡，在确保高内聚和低耦合同时，保证系统的结构清晰。

那实际编码时，需要注意什么呢？一下几点：

1：设计类时，考虑类间的耦合情况，合理减少类间交互，如果必要可以尝试使用内部类

2：尽可能使用private访问权限修饰属性成员，不外泄内部信息

3：满足需求设计前提，可以将类设置成final类

4：使用JavaBean规范，合理暴露属性成员

运用

这次使用shrio身份验证为例子展开讲：

Shiro进行身份验证涉及到几个参与方：

Subject ：用户对象抽象类，里面封装用户信息与用户相关动作，比如鉴权与授权委托操作

UsernameAndPasswordToken：用户身份信息(username， password)封装对象

SecurityManager ：shiro的大管家，负责资源调配

Realms：数据来源中间对象，负责与数据库，或者其他来源数据对接，转换成shiro可操作对象

Authentication：身份验证器

整个身份验证流程

UsernameAndPasswordToken

UsernameAndPasswordToken token = new UsernameAndPasswordToken("账号", "密码");

Subject类

public void login(AuthenticationToken token) throws AuthenticationException {Subject subject = securityManager.login(this, token);
}

SecurityManager 类

public Subject login(Subject subject, AuthenticationToken token) throws AuthenticationException {authenticate(token);
}public AuthenticationInfo authenticate(AuthenticationToken token) throws AuthenticationException {return this.authenticator.authenticate(token);
}

Authentication类

public final AuthenticationInfo authenticate(AuthenticationToken token){doAuthenticate(token);
}protected AuthenticationInfo doAuthenticate(AuthenticationToken authenticationToken)  {assertRealmsConfigured();Collection<Realm> realms = getRealms();if (realms.size() == 1) {return doSingleRealmAuthentication(realms.iterator().next(), authenticationToken);} else {return doMultiRealmAuthentication(realms, authenticationToken);}
}

结合上面核心代码，看下，一层一层委托下去，subject的login操作只需要委托给SecurityManager 类操作即可，不需要关注背后如何实现，只跟它朋友类SecurityManager 交互，这就是典型的迪米特法则使用。有兴趣大家跟踪下shiro鉴权操作，大同小异。

总结

迪米特法则使用过程中要明确的：

1：最少知道原则： A类减少与其他类的交互，其他类仅暴露A类需要方法或属性

2：不与陌生类交互：A类不可避免与陌生类交互，需要合理使用友元类(中介类)