欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 文旅 > 文化 > 设计模式:迪米特法则 - 最少依赖,实现高内聚低耦合

设计模式:迪米特法则 - 最少依赖,实现高内聚低耦合

2025/4/19 13:52:02 来源:https://blog.csdn.net/weixin_46619605/article/details/147201798  浏览:    关键词:设计模式:迪米特法则 - 最少依赖,实现高内聚低耦合

一、迪米特法则简介

迪米特法则(Law of Demeter,简称 LoD),也称为“最少知识法则”,核心思想是:一个对象应当对其他对象有最少的了解,仅与直接相关的对象交互。通过减少对象之间的耦合度,避免直接操作对象的内部结构,可以提高系统的灵活性和可维护性。

二、迪米特法则的核心原则

1.只与直接朋友交互:一个对象应只和直接依赖的对象交互,而避免操作其他对象的内部属性或方法。

2.避免链式调用:链式调用会加深对象间的依赖关系,增加系统复杂度和耦合度。

3.最小化接口暴露:隐藏实现细节,只对外提供必要的功能接口。

三、反例:违反迪米特法则的设计

场景:发动机 ,车 和 司机 3个类间的调用关系。

在反例中,Driver类直接依赖了Car和Engine,破坏了迪米特法则的核心思想。

1.Engine 类

public class Engine {private String model;// 构造器,初始化发动机模型public Engine(String model) {this.model = model;}// 获取发动机模型public String getModel() {return model;}
}

2.Car 类

此类暴露了Enginer 类。

public class Car {private Engine engine;public Car(Engine engine) {this.engine = engine;}public Engine getEngine() {return engine; // 直接暴露 Engine 对象}
}

3.Driver 类

此类直接访问了Engine 类和 Car类。

public class Driver {private Car car;public Driver(Car car) {this.car = car;}public void drive() {// Driver 直接访问 EngineEngine engine = car.getEngine();System.out.println("Driving a car with engine: " + engine.getModel());}
}

4.Main 类(测试代码)

public class Main {public static void main(String[] args) {Engine engine = new Engine("V8");Car car = new Car(engine);Driver driver = new Driver(car);driver.drive(); // 输出: Driving a car with engine: V8}
}

问题分析

1.违反迪米特法则

• Driver类直接操作了Engine,依赖了Car的内部实现细节。

• 如果Car类的实现发生变化(如更换发动机),Driver类也需要随之修改。

2.高耦合

• Driver同时依赖了Car和Engine,可维护性和扩展性降低。

3.职责分散

• Driver类承担了过多的职责,本应由Car提供的行为被Driver部分替代,导致职责不明确。

四、正例:符合迪米特法则的设计

在正例中,Driver类只与Car类交互,不直接访问Engine的内部实现。

1.Engine 类

(与反例相同,省略重复代码)

2.Car 类

与反例的差别是Car类不暴露Engine类。

public class Car {private Engine engine;public Car(Engine engine) {this.engine = engine;}// 隐藏内部实现细节,提供外部接口public void startCar() {System.out.println("Starting car with engine: " + engine.getModel());}
}

3.Driver 类

与反例的差异是 Driver类只与Car 交互。

public class Driver {private Car car;public Driver(Car car) {this.car = car;}public void drive() {// 只与 Car 类交互,避免直接访问 Enginecar.startCar();}
}

4.Main 类(测试代码)

public class Main {public static void main(String[] args) {Engine engine = new Engine("V8");Car car = new Car(engine);Driver driver = new Driver(car);driver.drive(); // 输出: Starting car with engine: V8}
}

说明:

• Engine类:负责管理发动机的属性(如模型)。

• Car类:负责管理汽车及其相关操作(如启动汽车)。

• Driver类:负责模拟司机与汽车的互动。

• Main类:测试和展示程序的执行过程。

优化分析

1.遵循迪米特法则:

• Driver类只与Car交互,而不直接访问Engine的内部实现。

• 如果Car类内部实现发生变化(如更换发动机类型),Driver类无需修改。

2.低耦合:

• Driver和Engine之间没有直接依赖,代码更易维护。

3.职责单一:

• Car负责与Engine的交互,Driver只负责操作Car。

4.扩展性高:

• 如果需要为Car增加新功能(如油耗管理),只需修改Car类,无需更改Driver。

五、正反例对比

通过清晰的职责划分和依赖关系解耦,正例设计严格遵循迪米特法则,避免了不必要的实现细节暴露,显著降低了系统的耦合度,提升了代码的可维护性和扩展性。

六、总结

迪米特法则通过限制类与类之间的直接依赖,使系统设计更加松耦合,显著提升代码的可维护性和扩展性。遵循这一法则,开发者可以减少因需求变更而引发的代码改动范围,从而保持系统的稳定性和灵活性。

在设计时,应优先隐藏实现细节,确保类之间职责单一、依赖清晰,以构建灵活易维护的高质量系统。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

热搜词