经典设计原则 - SOLID

SOLID 设计原则包含以下 5 种原则:

  • 单一职责原则(Single Responsibility Principle, SRP)
  • 开闭原则(Open Closed Principle, OCP)
  • 里式替换原则(Liskov Substitution Principle, LSP)
  • 接口隔离原则(Interface Segregation Principle, ISP)
  • 依赖反转原则(Dependency Inversion Principle, DIP)

单一职责原则

理解

单一职责原则的描述是,一个类或者模块只负责完成一个职责(或功能)。当然,单一职责原则不止是可以针对于模块或类,对于很多粒度都有效果,如函数、类、接口、模块等等,模块通常由多个类组成。

职责可以指模块变化的原因,从这个角度理解,单一职责原则表示不要存在超过一个导致模块变更的原因。

需要注意的是,不同的应用场景、不同阶段的需求背景、不同的业务层面,对同一个类的职责是否单一,可能会有不同的判定结果。

优点

遵循单一职责原则,将会有以下的优点:

  • 提高代码的可维护性:职责越少,复杂度越低,可读性更好,可维护性就更高
  • 降低代码变更的风险:职责越多,代码变更的可能性就越高,变更带来的风险也就越大
最佳实践

在实际开发中,出现以下现象有可能违反了单一职责原则:

  • 模块的变量、属性或代码行数过多
  • 模块的内部对外部依赖过多
  • 模块的私有方法过多
  • 难以给模块取一个合理的名称
  • 模块的大部分操作只针对几个属性

如出现上述情况,则需要判断是否对代码做职责分离,以遵循单一职责原则,最终应以提高内聚、降低耦合、保证代码的可维护性为主。

开闭原则

理解

开闭原则的描述是,软件实体(模块、类、方法等)应该“对扩展开放、对修改关

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SOLID原则中的依赖倒置原则(Dependency Inversion Principle,DIP)是指高层模块不应该依赖底层模块,二者都应该依赖于抽象接口;抽象接口不应该依赖于具体实现,而具体实现应该依赖于抽象接口。 简单来说,DIP原则就是通过接口来解耦高层模块和底层模块之间的依赖关系,使得系统更加灵活、可维护、可扩展。在设计和开发过程中,我们应该遵循DIP原则,尽可能使用接口或抽象类来定义模块之间的依赖关系,而不是直接依赖具体实现类。 举个例子,假设我们正在开发一个电商系统。我们有一个OrderService类,它依赖于一个底层模块的OrderDao类来实现订单数据的持久化。如果我们直接在OrderService类中实例化OrderDao对象,那么OrderService类就与OrderDao类紧密耦合,如果我们需要更换一种不同的数据持久化方案,那么就需要修改OrderService类的代码,违反了开闭原则(Open Close Principle,OCP)。 为了遵循DIP原则,我们可以先定义一个抽象的OrderDao接口,然后让OrderService类依赖于OrderDao接口。底层模块的具体实现类可以实现OrderDao接口,这样就可以实现数据持久化的功能,同时也可以轻松地更换不同的数据持久化方案,不需要修改OrderService类的代码。 总之,DIP原则是设计模式中非常重要的原则之一,它可以帮助我们构建更加灵活、可维护、可扩展的系统。在实际开发中,我们应该尽可能地遵循DIP原则,使用接口或抽象类来定义模块之间的依赖关系,降低模块之间的耦合度,提高系统的可维护性和可扩展性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值