面向对象编程之迪米特原则

迪米特原则英文全称为Law of Demeter，缩写是LOD，也称为最少知识原则（Least of Principle）。虽然名字不同，但描述的是同一个原则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现与调用者或者依赖者没有关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不管。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

迪米特法则还有一个英文解释就是Only talk to your immediate friends，翻译就是：只与直接的朋友通信。什么是最直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这样关系的类型很多，如组合、聚合、依赖等。

下面我们就以租房为例描述迪米特原则的应用：

在外工作的朋友比较了解，我们经常通过中介找房。我们设定的情况为：我只要求房间的面积和租金，其他的一概不管，中介将符合我要求的房子提供给我就可以。下面我们来看看这个示例：

我先来看看示例的UML图：

迪米特UML图.png

代码如下：

/**
 * 房子
 * @author liuguoquan
 *
 */
public class Room {

    public float area;
    public float price;
    
    public Room(float area, float price) {
        this.area = area;
        this.price = price;
    }

    @Override
    public String toString() {
        return "Room [area=" + area + ", price=" + price + "]";
    }
    
    
    
}

/**
 * 中介
 * @author liuguoquan
 *
 */
public class Mediator {

    List<Room> mRooms = new ArrayList<Room>();
    
    public Mediator() {
        
        for(int i = 0; i < 5; i++) {
            mRooms.add(new Room(10 + i, (10 + 1) * 200));
        }
    }
    
    public List<Room> getAllRooms() {
        return mRooms;
    }
}

/**
 * 租户
 * @author liuguoquan
 *
 */
public class Tenant {

    private float roomArea;
    private float roomPrice;
    private static final float DIFF_PRICE = 100.01f;
    private static final float DIFF_AREA = 0.01f;

    public void rentRomm(Mediator mediator) {
        List<Room> rooms = mediator.getAllRooms();

        for (Room room : rooms) {
            
            if (isSuitable(room)) {
                System.out.println("租到合适的房间啦!" + room.toString());
            }

        }
    }

    public boolean isSuitable(Room room) {

        return Math.abs(room.price - roomPrice) < DIFF_PRICE
                && Math.abs(room.area - roomArea) < DIFF_AREA;
    }
}

从上面的代码可以看到，Tenant依赖了Mediator类，而且依赖了Room类，还需要频繁的与Room类打交道。租户类的要求只是通过中介找到一间适合自己的房子罢了，如果把这些检测条件都放在Tenant类中，那么Mediator类的功能就会被弱化，而且导致Tenant与Room的耦合较高，因为Tenant必须知道许多关于Room的细节。当Room变化时Tenant也必须跟着变化。Tenant又与Mediator耦合，这就出现了许多纠缠不清的关系。这个时候我们需要分析谁是真正的“直接朋友”，在我们所说的情况下，显然是Mediator。

既然耦合太严重，我们就需要解耦。首先要明确的是，我们只和我们的朋友通信，就是指Mediator对象。必须将Room相关的操作从Tenant中移除，而这些操作应在属于Mediator。为此，我们进行重构，重构后的UML图如下：

迪米特原则UML重构.png

重构后的Mediator、代码如下：

/**
 * 中介
 * 
 * @author liuguoquan
 * 
 */
public class Mediator {

    List<Room> mRooms = new ArrayList<Room>();

    public Mediator() {

        for (int i = 0; i < 5; i++) {
            mRooms.add(new Room(10 + i, (10 + 1) * 200));
        }
    }

    public Room rentOut(float area,float price) {
        for(Room room : mRooms) {
            if (isSuitable(room, price, area)) {
                return room;
            }
        }
            
        return null;
    }

    public boolean isSuitable(Room room, float roomPrice, float roomArea) {

        return Math.abs(room.price - roomPrice) < Tenant.DIFF_PRICE
                && Math.abs(room.area - roomArea) < Tenant.DIFF_AREA;
    }
}

/**
 * 租户
 * @author liuguoquan
 *
 */
public class Tenant {

    private float roomArea;
    private float roomPrice;
    public static final float DIFF_PRICE = 100.01f;
    public static final float DIFF_AREA = 0.01f;

    public void rentRomm(Mediator mediator) {

        System.out.println("租到合适的房子了： " + mediator.rentOut(roomArea, roomPrice).toString());
    }

}

如上所示，租户不再需要知道太对关于Room的细节，比如与房东签合同，房东的房产证是不是真的等。当我们通过我们的“朋友”--中介租房后，所有的事情我们都通过与中介沟通就好了。

有点：

• 降低了复杂度
• 降低了耦合度
• 增加了稳定性