设计模式之迪米特原则

六大设计模式原则 之迪米特原则

迪米特原则又称为最少知识原则

一、定义

迪米特原则：指一个对象应该对于其他对象有最少的了解。

理解：简单来说一个类对自己所调用或者耦合的类有最少的了解，被调用的类内部实现与该类无关。

二、好处

可以有效的降低类之间的耦合度。

三、代码示例

我想大家都很熟悉，高三的时候因为课程紧张，尤其是一些所谓“学习狂人”（多为女生），经常以各种理由不上体育课，老师也不好说什么，只好每节课都认体育委员清点可以上课的人数，现在我们就来实现这一功能！

首先定义一个女生实体类，添加一个布尔指 判断是否可以上课

package gyblog.dimite;
public class Girl
{
//定义 女生是否可以取上体育课 false代表无法参加 ......
private boolean bool;
public Girl(boolean bool)
{
this.setBool(bool);
}
public boolean isBool()
{
return bool;
}
public void setBool(boolean bool)
{
this.bool = bool;
}
}

然后是体育委员类 用于判断该女生是否可以上课，并统计总量sum

package gyblog.dimite;
public class WeiYuan
{
//体育委员要知道有多少人不能去上课
private int sum = 0;
public int panDuan(Girl girl)
{
if (girl.isBool())
{
sum++;
}
return sum;
}
//我们假设这两个函数无法合并（这里是例子而已，实际可能因为 单一职责而不能合并）
public void count(int sum)
{
System.out.println("报告老师，一共有"+sum+"名女生无法参加体育课！");
}
}

再然后是老师类，实现叫体育委员清点人数的方法

package gyblog.dimite;
import java.util.ArrayList;
import java.util.List;
public class Teacher
{

//定义 本班女生集合
List<Girl> listGirls = new ArrayList<Girl>();
//初始化 女生集合
{
for(int i = 0;i < 12;i++)
{
listGirls.add(new Girl(false));
listGirls.add(new Girl(true));
}
}

public void toWeiYuan(WeiYuan weiYuan)
{
int sum = 0;
for (int i = 0; i < listGirls.size(); i++)
{
sum = weiYuan.panDuan(listGirls.get(i));

}
weiYuan.count(sum);
}
}

最后是场景类

package gyblog.dimite;
public class Client
{
public static void main(String[] args)
{
Teacher teacher = new Teacher();
WeiYuan zhangsan = new WeiYuan();
teacher.toWeiYuan(zhangsan);
}
}

下面是结果：

报告老师，一共有12名女生无法参加体育课！

好，我们看看这段代码有问题吗？没有！有！

其实是有问题的，我们看老师这个类，他需要两个类来帮助实现，一个是女生，一个是体育委员，要叫体育委员清点人数，那么体育委员类不可少，但是女生呢，老师不需要自己去清点，那么为什么老师要耦合女生呢，这就有一些问题了；还有，在老师类中我们共调用了2个体育委员的方法，这使我们对于体育委员类的了解更多了，这样也不是我们这个原则所提倡的，所以这段代码可以进行优化：

首先还是女生类，没有变化，也不可能有变化

package gyblog.dimite;
public class Girl
{
//定义 女生是否可以取上体育课 false代表无法参加 ......
private boolean bool;
public Girl(boolean bool)
{
this.setBool(bool);
}
public boolean isBool()
{
return bool;
}
public void setBool(boolean bool)
{
this.bool = bool;
}
}

接着是体育委员类，我们将它的所有方法都设置为private的，只有一个方法设置为public的，用于老师的调用。

package gyblog.dimite;
import java.util.List;
public class WeiYuan
{
//只暴露一个方法给老师类调用

//体育委员要知道有多少人不能去上课
private int sum = 0;
private List<Girl> listGirls ;
public WeiYuan(List<Girl> listGirls)
{
this.listGirls = listGirls;
}
private void panDuan(Girl girl)
{
if (girl.isBool())
{
sum++;
}
}
//我们假设这两个函数无法合并（这里是例子而已，实际可能因为 单一职责而不能合并）
private  void count(int sum)
{
System.out.println("报告老师，一共有"+sum+"名女生无法参加体育课！");
}

public void toTeacher()
{
//一个一个进行判断 是否可以上课
for (int i = 0; i < listGirls.size(); i++)
{
panDuan(listGirls.get(i));

}
//求出总人数
count(sum);
}
}

然后是老师类，现在老师类就干净了

package gyblog.dimite;

public class Teacher
{
public void toWeiYuan(WeiYuan weiYuan)
{
weiYuan.toTeacher();
}
}

最后还是场景类，我们将女生的初始化放在场景类中，由体育委员来寻找女生，这与老师无关

package gyblog.dimite;
import java.util.ArrayList;
import java.util.List;
public class Client
{
public static void main(String[] args)
{
Teacher teacher = new Teacher();
List<Girl> list = new ArrayList<Girl>();
for (int i = 0; i < 12; i++)
{
list.add(new Girl(true));
list.add(new Girl(false));
}
WeiYuan zhangsan = new WeiYuan(list);
teacher.toWeiYuan(zhangsan);
}
}

好了，我们运行一下：

报告老师，一共有12名女生无法参加体育课！

结果毫无问题！

总结一下：这样设计我们有哪些好处呢？

我们取消了老师对于女生的联系，降低了耦合度

我们减少了老师对于体育委员的了解，只调用了一个方法

整个设计更符合面向对象的设计