闲谈设计模式之迪米特原则

• 迪米特原则(Law of Demeter)
• • 示例代码
  • 总结

迪米特原则(Law of Demeter)

迪米特原则：俗称LOD，也称为最少知识原则(Least Knowledge Principie),其含义一个对象应该对其他对象了解最少，也就是说类与类之间耦合以及调用应该是极小的，类的内部实现与其调用者或者依赖者没有关系，调用者或依赖者应当知道合适且所需的调用方法即可。

示例代码

接下来以一段中介找房的例子进行分析

class Room(var area: Float, var price: Float) {

    override fun toString(): String {
        return "Room Message:\n area:$area \n price:$price"
    }

    fun equals(room: Room?): Boolean {
        return room!!.toString() == toString() && room.area == area && room.price == price
    }
}

/**
 * 中介
 * */
class Mediator {

    private val rooms = ArrayList<Room>()

    init {
        for (size in 0..4) {
            val area = size + 49f
            rooms.add(Room(area, area * 15))
        }
    }

    fun getRooms(): List<Room> {
        return rooms
    }
}

/**
 * 租户
 */
class Tenant {

    fun rentRoom(area: Float, price: Float, mediator: Mediator) {
        val room = Room(area, price)
        mediator.getRooms().forEach {
            if (it.equals(room)){
                println("找到合适的房间准备租房")
                print(it.toString())
            }
        }
    }
}
           

上述代码乍一看是没什么问题，但是再结合以下UML类图来看就会发现耦合有些严重了。

在这个UML类图中就可以很清晰知道为什么耦合性很高了，当Room类修改增加属性的时候，那么不管是中介还是租户都会受到影响，那么能不能让中介不止负责管理所有房间信息，并且为租户去做匹配筛选，当有合适或者找不到房子的时候通知给租户就行了呢？让Tenant直接去掉对Room的持有，避免room改变也会影响到租户仅仅影响到中介呢？

代码接招：

/**
 * 中介
 * */
class Mediator {

    private val rooms = ArrayList<Room>()

    init {
        for (size in 0..4) {
            val area = size + 49f
            rooms.add(Room(area, area * 15))
        }
    }

    fun rentOut(
        area: Float, price: Float,
        suceess: (message: String) -> Unit, fail: (message: String) -> Unit
    ) {
        val room = Room(area, price)
        rooms.forEach {
            if (it.equals(room)) {
                suceess("找到合适的房间准备租房\n${it.toString()}")
                return
            }
        }
        fail("很抱歉找不到合适的房间")
    }
}

/**
 * 租户
 */
class Tenant {

    fun rentRoom(area: Float, price: Float, mediator: Mediator) {
        val room = Room(area, price)
        mediator.rentOut(area, price,
            { message -> print(message) },
            { failMessage -> print(failMessage) })
    }
}
           

根据修改好的代码相应UML类图如下：

从新的UML类图中以及源码结合来看，Room不管在怎么修改也不会影响到Tenant，而Mediator只需要专注于为Tenant筛选出合适的房间。

总结

LOD并不是都适用任何场景，但是活用LOD原则以及其他原则的配合可以极大程度的减少代码冗余耦合度，设计模式的基本核心原理就是活用六大原则应对实际开发场景总结实践出来的一种代码编写模式，一个优秀程序员必须要时刻把握六大原则以及设计模式的合理运用，只有这样才会使得代码具有可阅性可造性。否则随着业务场景的拓展代码将会越来越难维护甚至会把自己玩死。当然有些“机智的人“知道代码快玩死常常当“甩手掌柜”跑路。但睿智的人是知道何时精简优化代码架构甚至及时重构摆脱这种困境。