设计模式六大原则

设计模式六大原则


单一职责原则(SRP):

一个类应该只负责一个功能领域中的相应职责。例如,一个计算器类应该只负责计算,而不应该包含其他不相关的功能。

开闭原则(OCP):

软件实体应该对扩展开放,对修改关闭。例如,如果需要添加一种新的计算方法,应该通过新增类或方法来实现,而不是修改原有的类或方法。

里氏替换原则(LSP):

子类对象应该能够替换其父类对象,而不影响程序的正确性。例如,一个正方形类继承自矩形类,应该能够代替矩形类使用。

依赖倒置原则(DIP):

高层模块不应该依赖低层模块,二者都应该依赖其抽象。例如,一个打印机类不应该依赖于具体的操作系统,而应该依赖于抽象的操作系统接口。

接口隔离原则(ISP):

客户端不应该依赖于它不需要的接口。例如,一个文件上传接口应该只包含上传文件的方法,而不应该包含其他不相关的方法。
接口隔离原则要求:

  1. 每个接口承担单一的角色。如序列化接口只标识可序列化,而不标识是否可以clone。
  2. 接口中的方法尽量少
  3. 不要让接口的实现类依赖于不需要的方法

迪米特法则(LoD):

又称最小知识原则。一个对象应该对其他对象保持最少的了解。例如,一个订单类不应该直接调用库存类中的方法,而应该通过调用库存类的外部接口实现。


举个例子,迪米特法则: 假设有一个学校管理系统,其中包含了学生和班级两个类。按照最小知识原则,如果想获取某个班级的学生数量,应该通过班级类中的方法来获取,而不是通过学生类中的方法获取所有学生对象,然后再数出特定班级的学生数量。这样能够有效减少类与类之间的依赖关系,降低耦合度,提高系统的灵活性和可维护性。

再例如,以依赖倒置原则为例:如果有一个电商系统需要支持不同的支付方式,按照依赖倒置原则,应该定义一个支付接口,然后定义具体的支付方式实现类,以便在系统中方便地切换支付方式。这样,系统的高层模块(如订单处理模块)就可以依赖于支付接口,而不需要依赖于具体的支付方式实现类。

你可能感兴趣的:(设计模式,后端)