软件构造SOLID设计原则2021-06-30

SOLID设计原则

软件构造SOLID五大设计原则,如果能够严格遵循这五大设计原则进行软件设计,那么我们程序的健壮性、可复用性、可扩展性等各方面将会相当优秀。
SOLID设计原则如下:

(SRP) The Single Responsibility Principle --------- 单一责任原则
(OCP) The Open-Closed Principle ------------------- 开放-封闭原则
(LSP) The Liskov Substitution PrincipleLiskov ---- 里氏替换原则
(ISP) The Interface Segregation Principle ---------- 接口隔离原则
(DIP) The Dependency Inversion Principle -------- 依赖转置原则

单一责任原则(SRP)

一个类负责一个责任,不应有多于1个的原因使得一个类发生变化。如果有就将他们拆分开
尽可能地将功能分割,以达到不应该有多于一个原因让你的ADT发生变化的目的。如果多个责任(功能)放在一个类中就有可能在未来某一个功能发生变化的时候影响到整个类,从而影响到整个程序的很大一部分实现。

例如,在一个接口中,既要负责玩游戏,又要负责看书写作业。这就不符合单一责任原则,我们就需要将他们拆分开。

interface Modem {
public void play(int p);
public void end();
public void write(String c);
public String read();
}
interface Pgame {
public void play(int p);
public void end();
}
interface Study {
public void write(String c);
public String read();
}

开放-封闭原则(OCP)

对扩展性的开放:模块的行为应是可扩展的,模块可表现出新的行为以满足需求的变化。
对修改的封闭:模块自身的代码是不应被修改的,要去扩展出新的类然后调用新的类。

典型的违反OCP的例子是大量的使用 if-else / switch-case 语句,这给维护造成了极大的麻烦。所以应对的方法是让客户端传入接口的不同子类型,而在ADT中只需要统一的调用接口中共有的方法即可。

如果有多种类型的Plane,那么针对每一种新出现的Plane,不得不修改Plane类的内部具体实现。
通过构造一个抽象的Plane类:AbstractPlane,该抽象类中包含针对所有类型的Plane都通用的代码,从而实现了对修改的封闭;当出现新的Plane类型时,只需从该抽象类中派生出具体的子类ConcretePlane即可,从而支持了对扩展的开放。
在这里插入图片描述

里氏替换原则(LSP)

子类型必须能够替换其基类型,派生类必须能够通过其基类的接口使用,客户端无需了解二者之间的差异。

接口隔离原则(ISP)

不能强迫客户端依赖于它们不需要的接口,只提供必需的接口:这能够避免接口污染,避免胖接口。

可以将胖接口可分解为多个小的接口,不同的接口向不同的客户端提供服务,客户端只访问自己所需要的端口。

依赖转置原则(DIP)

高层模块不应该依赖于低层模块,二者都应该依赖于抽象。
抽象不应该依赖于实现细节,实现细节应该依赖于抽象。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 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、付费专栏及课程。

余额充值