设计模式六大原则

设计模式六大原则如下：

 

一、单一职责原则（Single Responsibility Principle，SRP）

 

一个类应该只有一个引起它变化的原因。即一个类只负责一项职责，这样可以降低类的复杂度，提高类的可读性、可维护性和可扩展性。

 

例如，一个用户管理类只负责用户信息的管理，如用户的创建、查询、更新等操作，而不应该同时负责与用户相关的其他业务逻辑，如用户订单的处理等。

 

二、开闭原则（Open Closed Principle，OCP）

 

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。即当软件需要增加新功能时，应该通过扩展现有代码来实现，而不是修改现有代码。

 

比如，有一个图形绘制的程序，最初只支持绘制圆形和矩形。如果要添加绘制三角形的功能，不是去修改已有的绘制圆形和矩形的代码，而是通过扩展的方式新增一个绘制三角形的类，这样不会影响到已有的功能。

 

三、里氏替换原则（Liskov Substitution Principle，LSP）

 

所有引用基类（父类）的地方必须能透明地使用其子类的对象。即子类可以扩展父类的功能，但不能改变父类原有的功能。

 

例如，有一个函数接收一个父类类型的参数，如果传入一个子类对象，函数应该能够正常工作，并且不会出现意外的结果。

 

四、依赖倒置原则（Dependence Inversion Principle，DIP）

 

高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。即要面向接口编程，而不是面向实现编程。

 

比如，在一个分层架构的系统中，上层的业务逻辑层不应该直接依赖下层的数据访问层的具体实现类，而是应该依赖数据访问层的接口。这样当数据访问层的实现发生变化时，不会影响到业务逻辑层。

 

五、接口隔离原则（Interface Segregation Principle，ISP）

 

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。即接口应该尽量细化，使其只包含调用者需要的方法，避免不必要的方法暴露给调用者。

 

例如，一个类实现了一个大而全的接口，但实际上只需要其中的一部分方法，这样会导致该类被迫实现一些不需要的方法，增加了类的复杂性。可以将大接口拆分成多个小接口，让类只实现它需要的接口。

 

六、迪米特法则（Law of Demeter，LoD）

 

也称为最少知识原则，一个对象应该对其他对象有尽可能少的了解。即一个类应该尽量少地与其他类发生相互作用，降低类之间的耦合度。

 

例如，一个类 A 中的方法需要调用类 B 的方法，应该通过类 A 能够直接访问的对象来调用类 B 的方法，而不是直接去获取类 B 的实例并调用其方法。这样可以减少类之间的依赖关系，提高系统的可维护性。