《设计模式》——迪米特法则
定义
其实《设计模式之禅》关于原则的部分，我最喜欢的就是《迪米特法则》没什么特殊原因，前段时间部门培训，让我出个培训内容，就是选择的迪米特法则。其实原因很简单，就因为看它名字都不知道究竟是拿来干啥的。
先臭美一下《设计模式》——目录，然后让我们进入正题。
所以究竟什么是迪米特法则呢？
迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP），虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
对于这个定义说实话我还是挺喜欢的，但也是生活中我很难做到的一点，那就是“我就调用这么多，其他的我一概不关心”。其实在小的公司，这样的性格是不好的，毕竟很难做到一个萝卜一个坑，大家或多或少都需要承担一些职能外的任务。而且从个人成长的角度来说，其实也是参与越多，收获也会越多。
有感一段废话，可以跳过不看。职场中有一种情况，那就是A只做十件事，而且十件事都完成的很好；而B需要做一百件事，但是有一件事没有做好。这两个人谁的年终评估会更高一些呢？当然，这里不是劝大家“各人自扫门前雪,莫管他人瓦上霜”（虽然，这是迪米特法则提倡的）。只是有这么几个建议：
- 能力范围内，多自己有所成长的，能多参与还是多参与（不要超能力，不要超量）
- 既然参与了，能做好就尽己所能做到最好
- 如果一旦失败了要用于承担，实事求是说明情况，而不是抱怨于自己比别人多做了多少
- 当领导职能看到自己做错的（不是只说你错了，毕竟确实有问题。要看其他相关福利待遇、boss对你的日常态度等方方面面），而不是作对的时，优先考虑一下自己的方法以及态度
- 如果如上都没有问题，可以考虑换个舒服点的环境
当然，上面这么多废话，主要目的就是想说明，当我们的代码不遵守迪米特法则的时候，一旦出现问题，要面临这么多的麻烦事。毕竟你作为主角还能为自己申辩一下，而我们可怜的代码，只能被别人吐槽“这代码真烂”，却无力反抗啊。
而《设计模式之禅》中，迪米特法则对类的低耦合做出了如下四层定义：
- 只和朋友交流
- 朋友之间也是有距离的
- 是自己的就是自己的
- 谨慎使用Serializable
只和朋友交流
迪米特法则还有一个英文解释是：Only talk to your immediate friends（只与直接的朋友通信。）什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系。
对于一个吃货来说，这个时候必须要吃可乐鸡翅了！
为了吃可乐鸡翅的，我们总共有两种实现途径：
- 自己做
- 去饭店
自己做
先说说自己做，最基本的，我们需要知道配料，还需要知道制作可乐鸡翅的菜谱。当然，这些都不重要。作为一个懒汉来说，我最怕的是还要去购买食材，买回来以后还要自己制作！
步骤：
- 把鸡翅清洗干净，划花刀。加入蚝油、酱油、盐、料酒、姜，腌制鸡翅。（天气炎热，最好放入冰箱，避免发臭。腌制半个小时左右）
- 在锅里加入适量油，把腌制过后的鸡翅放入锅中两面煎黄。
- 把刚才腌制的调料一起倒入，加入可乐，大火烧开，然后收汁 ！
- 健康又卫生的可乐鸡翅就做好了！
以上可乐鸡翅制作步骤来自下厨房
public class Blog {
@Test
public void order() {
MySelf mySelf = new MySelf();
mySelf.order(new Waitress());
}
}
class ColaChickenWings {
private ChickenWings chickenWings;
private Cola cola;
public boolean cooked() {
return 0 == new Random().nextInt(5);
}
public ChickenWings getChickenWings() {
return chickenWings;
}
public void setChickenWings(ChickenWings chickenWings) {
this.chickenWings = chickenWings;
}
public Cola getCola() {
return cola;
}
public void setCola(Cola cola) {
this.cola = cola;
}
/**
* 鸡翅
*/
class ChickenWings {
}
/**
* 可乐
*/
class Cola {
}
}
class MySelf {
public void order(Waitress waitress) {
ColaChickenWings colaChickenWings = new ColaChickenWings();
// 买鸡翅
if (null == colaChickenWings.getChickenWings()) {
colaChickenWings.setChickenWings(colaChickenWings.new ChickenWings());
}
// 买可乐
if (null == colaChickenWings.getCola()) {
colaChickenWings.setCola(colaChickenWings.new Cola());
}
waitress.orderColaChickenWings(colaChickenWings);
}
}
class Waitress {
public void orderColaChickenWings(ColaChickenWings colaChickenWings) {
if (null != colaChickenWings) {
while (true) {
if (colaChickenWings.cooked()) {
System.out.println("美味的可乐鸡翅出锅喽！！！");
break;
} else {
System.out.println("马上就好了");
}
}
}
}
}
去饭店
说到去饭店，这个步骤就复杂了，我们到饭店以后还要高喊一声：
之后只需要等上那么一会，可爱的服务员小姐姐就把可乐鸡翅端到我面前来了！！！惊不惊喜？意不意外？
显而易见，去饭店这种选择就符合了我们的最小知识原则，而我们只需要与可爱的服务员小姐姐成为朋友，她就会点好菜，再给你端上来就好了，而不需要我们去了解可乐鸡翅那么繁琐的制作过程。
public class Blog {
@Test
public void order() {
MySelf mySelf = new MySelf();
mySelf.order(new Waitress());
}
}
class ColaChickenWings {
private ChickenWings chickenWings;
private Cola cola;
public boolean cooked() {
// 买鸡翅
if (null == chickenWings) {
chickenWings = new ChickenWings();
}
// 买可乐
if (null == cola) {
cola = new Cola();
}
return 0 == new Random().nextInt(5);
}
/**
* 鸡翅
*/
class ChickenWings {
}
/**
* 可乐
*/
class Cola {
}
}
class MySelf {
public void order(Waitress waitress) {
waitress.orderColaChickenWings();
}
}
class Waitress {
public void orderColaChickenWings() {
ColaChickenWings colaChickenWings = new ColaChickenWings();
while (true) {
if (colaChickenWings.cooked()) {
System.out.println("美味的可乐鸡翅出锅喽！！！");
break;
} else {
System.out.println("马上就好了");
}
}
}
}
当然，这里还是需要注意一点，那就是虽然老话说“朋友的朋友是朋友”，但是你找朋友的朋友借个钱试试？
一个类只和朋友交流，不与陌生类交流，不要出现getA().getB().getC().getD()这种情况（在一种极端的情况下允许出现这种访问，即每一个点号后面的返回类型都相同），类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类除外。
朋友之间也是有距离的
人和人之间是有距离的，太远关系逐渐疏远，最终形同陌路；太近就相互刺伤。对朋友关系描述最贴切的故事就是：两只刺猬取暖，太远取不到暖，太近刺伤了对方，必须保持一个既能取暖又不刺伤对方的距离。迪米特法则就是对这个距离进行描述，即使是朋友类之间也不能无话不说，无所不知。
还是说我们的可乐鸡翅，当美丽的小姐姐想要吃可乐鸡翅的时候怎么办呢？还是两个情况：
- 我们很熟
- 我们不熟
我们很熟
由于我对小姐姐比较熟悉，知道一些小姐姐的要求，在做可乐鸡翅的时候自然需要考虑进去
- 可乐要0卡的
- 小姐姐讨厌蒜的味道
- 小姐姐喜欢吃鲜鸡翅，不能是冻的
- 小姐姐减肥，不能放太多油
- 小姐姐……
public class Blog {
@Test
public void order() {
MySelf mySelf = new MySelf();
mySelf.cookColaChickenWings(new CuteGirl());
}
}
class ColaChickenWings {
private Calorie calorie = new Calorie();
private Garlic garlic = new Garlic();
public Calorie getCalorie() {
return calorie;
}
public void setCalorie(Calorie calorie) {
this.calorie = calorie;
}
public Garlic getGarlic() {
return garlic;
}
public void setGarlic(Garlic garlic) {
this.garlic = garlic;
}
class Calorie {
}
class Garlic {
}
}
class MySelf {
public void cookColaChickenWings(CuteGirl cuteGirl) {
ColaChickenWings colaChickenWings = new ColaChickenWings();
if (null != colaChickenWings.getCalorie()) {
colaChickenWings.setCalorie(null);
}
if (null != colaChickenWings.getGarlic()) {
colaChickenWings.setGarlic(null);
}
cuteGirl.eat(colaChickenWings);
}
}
class CuteGirl {
public void eat(ColaChickenWings colaChickenWings) {
if (null != colaChickenWings.getGarlic() || null != colaChickenWings.getCalorie()) {
System.out.println("不好吃，再也不理你了");
}
}
}
我们不熟
那还管什么，我还不想怎么做怎么做啊！
public class Blog {
@Test
public void order() {
MySelf mySelf = new MySelf();
mySelf.cookColaChickenWings(new CuteGirl());
}
}
class ColaChickenWings {
private Calorie calorie = new Calorie();
private Garlic garlic = new Garlic();
public Calorie getCalorie() {
return calorie;
}
public void setCalorie(Calorie calorie) {
this.calorie = calorie;
}
public Garlic getGarlic() {
return garlic;
}
public void setGarlic(Garlic garlic) {
this.garlic = garlic;
}
class Calorie {
}
class Garlic {
}
}
class MySelf {
public void cookColaChickenWings(CuteGirl cuteGirl) {
cuteGirl.eat(new ColaChickenWings());
}
}
class CuteGirl {
public void eat(ColaChickenWings colaChickenWings) {
if (null != colaChickenWings.getGarlic()) {
colaChickenWings.setGarlic(null);
}
if (null != colaChickenWings.getCalorie()) {
colaChickenWings.setCalorie(null);
}
System.out.println("味道还行");
}
}
看看，是不是省心了很多（是不是注孤生不在考虑范围内）
一个类公开的public属性或非法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此，为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少public方法和属性，是否可以修改为private、package-private（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等。
迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。
是自己的就是自己的
这一条又说明了什么？可乐鸡翅还是要会做的！毕竟就算饭店倒闭了，就算小姐姐离开了我，至少我还是有可乐鸡翅吃的！
在实际应用中经常会出现这样一个方法：放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
而从前面的例子也可以看得出来，实际就是尽可能将类自身能够完成的判断、流程等，在该类内部完成，只对外提供一个调取的public即可，而不是将这些都暴露在外，让调用的类自己去判断（比如点菜，和陌生小姐姐吃可乐鸡翅）。
谨慎使用Serializable
好吧，又冒出来了一个新名词Serializable，它究竟是什么意思呢？
序列化 (Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间，对象将其当前状态写入到临时或持久性存储区。以后，可以通过从存储区中读取或反序列化对象的状态，重新创建该对象。
好了，下面来看看在《设计模式之禅》中关于这部分的介绍：
在一个项目中使用RMI（Remote Method Invocation，远程方法调用）方式传递一个VO（Value Object，值对象），这个对象就必须实现Serializable接口（仅仅是一个标志性接口，不需要实现具体的方法），也就是把需要网络传输的对象进行序列化，否则就会出现NotSerializableException异常。突然有一天，客户端的VO修改了一个属性的访问权限，从private变更为public，访问权限扩大了，如果服务器上没有做出相应的变更，就会报序列化失败，就这么简单。
对于这段话，我个人的理解是：“ 能 序 列 化 就 序 列 化 ， 不 序 列 化 可 能 会 挂 ！ \color{red}{能序列化就序列化，不序列化可能会挂！} 能序列化就序列化，不序列化可能会挂！”