当前位置：首页 > news >正文

设计模式六大原则：迪米特法则详细说明和案例示范

news 2025/11/26 18:59:14

设计模式六大原则之：迪米特法则（Law of Demeter）

迪米特法则（Law of Demeter，LoD），又称为“最少知识原则”（Principle of Least Knowledge），是设计模式六大原则之一。它强调对象之间的交互应尽可能少，避免产生过于复杂的耦合关系，从而提高系统的可维护性和可扩展性。

1. 什么是迪米特法则？

迪米特法则的核心思想是：

只与直接的朋友通信：一个对象应当只与那些与它关系密切的对象直接通信，而不应该依赖于太多的其他对象。
避免过度依赖：对象之间的依赖关系应该尽量减少，避免形成复杂的依赖链。

在实际开发中，这意味着我们应该设计简洁的接口，避免对象过度依赖于其他对象的内部细节，从而减少对象之间的耦合度。

2. 错误示范：以电商交易系统为例

假设我们在电商系统中设计了一个订单处理类OrderProcessor，它直接依赖多个其他类的细节操作：

class OrderProcessor {private User user;private PaymentService paymentService;private ShippingService shippingService;public OrderProcessor(User user, PaymentService paymentService, ShippingService shippingService) {this.user = user;this.paymentService = paymentService;this.shippingService = shippingService;}public void processOrder(Order order) {// 获取用户的支付信息PaymentInfo paymentInfo = user.getPaymentInfo();// 进行支付paymentService.processPayment(paymentInfo, order.getTotalAmount());// 获取用户的地址信息Address address = user.getAddress();// 进行发货shippingService.shipOrder(order, address);}
}

在这个设计中，OrderProcessor类直接依赖User、PaymentService和ShippingService类的内部细节，违反了迪米特法则。如果User类的实现发生变化，比如支付信息的获取方式发生了改变，OrderProcessor类就可能需要随之修改，这增加了系统的耦合度和维护成本。

3. 正确示范：应用迪米特法则

为了遵循迪米特法则，我们可以通过引入中介类来减少对象之间的直接依赖：

 class OrderProcessor {private PaymentService paymentService;private ShippingService shippingService;public OrderProcessor(PaymentService paymentService, ShippingService shippingService) {this.paymentService = paymentService;this.shippingService = shippingService;}public void processOrder(Order order, UserFacade userFacade) {// 通过UserFacade获取支付和地址信息PaymentInfo paymentInfo = userFacade.getPaymentInfo();Address address = userFacade.getAddress();// 进行支付paymentService.processPayment(paymentInfo, order.getTotalAmount());// 进行发货shippingService.shipOrder(order, address);}
}class UserFacade {private User user;public UserFacade(User user) {this.user = user;}public PaymentInfo getPaymentInfo() {return user.getPaymentInfo();}public Address getAddress() {return user.getAddress();}
}

在这个设计中，OrderProcessor不再直接依赖User类的内部实现细节，而是通过UserFacade类与User类进行交互。这样，当User类的实现发生变化时，只需要修改UserFacade类，OrderProcessor类无需修改。这种设计减少了类之间的耦合度，提高了系统的灵活性和可维护性。