设计模式六大原则

发布于:2024-12-23 ⋅ 阅读:(19) ⋅ 点赞:(0)

1、开闭原则(Open - Closed Principle,OCP)

定义:

软件实体(类、模块、函数等)应该对扩展开放,对修改关闭。这意味着当需要对软件系统进行功能扩展时,应该通过添加新的代码(类、模块、函数等)来实现,而不是修改已有的代码。

示例:

以一个图形绘制系统为例,假设有一个绘制圆形的类CircleDrawer,如果要添加绘制矩形的功能,不应该直接修改CircleDrawer类。而是创建一个新的RectangleDrawer类来实现绘制矩形的功能。这样,在不修改已有CircleDrawer类的情况下扩展了系统的功能。

好处:

开闭原则可以提高软件系统的可维护性和可扩展性。因为修改已有的代码可能会引入新的错误或者影响到其他部分的功能,而通过添加新的代码来扩展功能可以将新功能的影响范围控制在新添加的部分。

2、里氏替换原则(Liskov Substitution Principle,LSP)

定义:

所有引用基类(父类)的地方必须能透明地使用其子类的对象。也就是说,子类对象应该能够替换父类对象,并且程序的行为和结果不会发生改变。

示例:

假设有一个基类Vehicle,有一个方法calculateSpeed()。有两个子类Car和Bicycle。根据里氏替换原则,在任何使用Vehicle类型对象来调用calculateSpeed()方法的地方,无论是使用Car对象还是Bicycle对象,都应该能够正确地计算出速度,并且不会导致程序出现错误或者不符合预期的行为。

好处:

里氏替换原则有助于保证程序的正确性和稳定性。它强制要求子类在继承父类时,不能改变父类原有的行为语义,从而避免了在多态调用时出现意外的结果。

3、依赖倒置原则(Dependency Inversion Principle,DIP)

定义:

高层模块不应该依赖低层模块,两者都应该依赖抽象;抽象不应该依赖细节,细节应该依赖抽象。简单来说,就是要面向接口编程,而不是面向具体的实现编程。

示例:

在一个电商系统中,高层的订单处理模块不应该直接依赖于低层的数据库存储模块。而是应该定义一个抽象的存储接口,订单处理模块依赖这个抽象接口,而数据库存储模块实现这个抽象接口。这样,如果要更换数据库存储方式(如从关系型数据库转换为非关系型数据库),只要新的存储模块实现了相同的抽象接口,就不会影响到订单处理模块。

好处:

依赖倒置原则可以降低模块之间的耦合度,提高系统的灵活性和可维护性。当系统的底层实现发生变化时,只要抽象接口不变,高层模块就不需要修改。

4、单一职责原则(Single Responsibility Principle,SRP)

定义:

一个类应该只有一个引起它变化的原因。也就是说,一个类应该只负责一项职责。

示例:

以一个用户管理系统为例,User类应该只负责与用户信息相关的操作,如获取用户姓名、年龄、修改用户密码等。而不应该同时负责用户登录验证的功能,登录验证应该由另一个专门的LoginValidator类来负责。这样,当用户信息的管理规则发生变化(如添加新的用户属性)时,只需要修改User类;当登录验证的方式发生变化(如添加验证码验证)时,只需要修改LoginValidator类。

好处:

单一职责原则可以使类的职责更加明确,提高类的内聚性,降低类的复杂度。这样在系统发生变化时,更容易定位和修改相关的代码,减少了因为一个类的职责过多而导致的代码修改风险。

5、接口隔离原则(Interface Segregation Principle,ISP)

定义:

客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。

示例:

假设有一个打印机接口Printer,包含了打印文档、扫描文档、传真文档等多个方法。但对于一个只需要打印功能的客户端(如一个简单的文本编辑器)来说,它不应该依赖包含扫描和传真功能的打印机接口。应该将打印机接口拆分成更小的接口,如Printable接口(只包含打印方法)、Scannable接口(只包含扫描方法)、Faxable接口(只包含传真方法),让客户端只依赖它需要的接口。

好处:

接口隔离原则可以避免客户端依赖不需要的接口,减少了接口的臃肿和客户端的负担。同时也提高了系统的灵活性和可维护性,因为当某个接口的功能发生变化时,只有依赖这个接口的客户端才会受到影响。

6、米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle)

定义:

如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。

示例:

在一个公司管理系统中,员工类Employee可能会使用部门类Department的一些信息。但是根据迪米特法则,Employee类不应该直接访问Department类的内部成员(如其他员工的信息),而是应该通过Department类提供的有限的接口(如获取部门经理的信息)来获取所需的信息。

好处:

迪米特法则可以降低类之间的耦合度,使系统的结构更加松散,提高系统的可维护性和可扩展性。因为一个类对其他类的了解越少,当其他类发生变化时,对这个类的影响就越小。