昆山网站开发ikelvwordpress后台下载

当前位置： 首页 > news >正文

昆山网站开发ikelv,wordpress后台下载,如何学习wordpress,有哪些做头像的网站单一职责原则#xff1a;https://blog.csdn.net/dmk877/article/details/143447010 在前面我们学习了单一职责原则#xff0c;今天来一起学习一下SOLID原则中的开闭原则(Open-Closed Principle, OCP) 通过本篇博客你将学到到以下内容 ①什么是开闭原则 ②如何实现开闭原则 ③…单一职责原则https://blog.csdn.net/dmk877/article/details/143447010 在前面我们学习了单一职责原则今天来一起学习一下SOLID原则中的开闭原则(Open-Closed Principle, OCP) 通过本篇博客你将学到到以下内容 ①什么是开闭原则 ②如何实现开闭原则 ③两个开闭原则的案例 一、什么是开闭原则 首先我们来看下开闭原则的定义: Software entities like classes,modules and functions should be open for extension but closed for modifications. 软件实体如类、模块和函数应该对扩展开放对修改关闭。 怎么理解这句话呢这句话最重要的就是对扩展开放对修改关闭 对扩展开放:当有新的需求或变化时可以对现有代码进行扩展以适应新的需求对修改关闭:需求一旦开发完成就可以独立完成其工作而不要对已有代码做修改 二、如何实现开闭原则 一般用来提高扩展性的方法有多态、依赖注入、面向抽象而非面向具体编程怎么利用多态、依赖注入、面向抽象而非具体编程来实现“对扩展开放、对修改关闭”呢接下来我举两个例子相信通过这两个例子你对开闭原则的理解会更加深入。 2.1 举例一 什么依赖注入什么是面向抽象而非具体的编程 // 将图形进行抽象 public interface Shape {//..} // 圆形 public class Cirlce implements Shape {//..} // 三角形 public class Triangle implements Shape {//..} // 长方形 public class Rectangle implements Shape {//..}public class Demo {private Shape shape; // 基于接口而非实现的编程// 依赖注入public Demo(Shape shape) {this.shape shape;} }以上这段伪代码就是基于接口而非具体编程将图形共同的属性和方法抽取到Shape接口中然后针对不同的图形会分别实现接口中的功能。那么问题来了为什么要这么做呢来一个完整的例子通过这个例子你就会明白为什么要这么做 2.2 举例二 电商支付系统 假如我们在开发电商平台的支付系统当前支付的方式有Alipay、WechatPay这个支付系统如何设计呢首先可以定义个PayManager来统一管理支付。代码如下 public class PayManager {public void pay(int payMode) {if (payMode 1) {aliPay();} else if (payMode 2) {wechatPay();}}private void aliPay() {System.out.println(调用 alipay 接口);}private void wechatPay() {System.out.println(调用 wechatpay 接口);} }可以看到在PayManager的pay方法里根据传递的参数来判断应该使用哪种支付方式貌似没啥问题但是随着业务的发展需要增加银行卡支付方式BankCardPay应该怎么处理呢需要修改两个地方 pay方法里增加一个if分支写一个bankcardPay方法 代码如下 public class PayManager {public void pay(int payMode) {if (payMode 1) {aliPay();} else if (payMode 2) {wechatPay();} else if (payMode 3) {// 修改点一增加一个if分支bankcardPay();}}private void aliPay() {System.out.println(调用 alipay 接口);}private void wechatPay() {System.out.println(调用 wechatpay 接口);}// 修改点二增加一个bankcardPay方法private void bankcardPay() {System.out.println(调用 bankcardpay 接口);} }有没有发现一个问题PayManager里的pay方法进行了修改假如后续还有其它支付方式的增加是不是每次都要增加一个if语句呢这么做有什么弊端呢 上述修改方式对现有的代码进行了修改有潜在的危险因为我们的pay方法在新增支付方式之前已经测试过并上线你新增了一个支付方式对其进行了修改是不是还要重新测试一遍呢? 另外这种写法其实违背了开闭原则即“对扩展开放对修改关闭”哪里违背了呢其实就是对扩展支持的不好新增一种支付方式需要修改核心代码逻辑风险很大。那么我们应该怎么去设计它呢案例一中可以了解到什么是面向抽象而非具体编程同样Shape接口一样是不是可以对支付方式进行抽象呢当然可以定义一个接口Payment在其中抽象一个pay方法用来完成支付功能它的代码如下 public interface Payment {public void pay(); }所有的支付方式都需要实现此接口当前只支持AliPay和WechatPay这两种支付方式它们的代码如下 public class AliPay implements Payment {Overridepublic void pay() {System.out.println(调用 alipay 接口);} }public class WechatPay implements Payment {Overridepublic void pay() {System.out.println(调用 WechatPay 接口);} }PayManager的代码如下 public class PayManager {// 依赖注入public void pay(Payment payment) {payment.pay();} }然后就是如何去调用 public class TestPay {public static void main(String[] args) {Payment wechatPay new WechatPay();PayManager.pay(wechatPay);} }可以看到第三行需要哪种支付方式直接创建其对象并将其传递个PayManager的pay方法即可。此时需要增加一个银行卡支付功能应该如何处理呢只需要增加一个BankCardPay类并实现Payment接口即可代码如下 public class BankCardPay implements Payment {Overridepublic void pay() {System.out.println(调用 BankCardPay 接口);} }这样就已经修改完成调用方法也跟上面一样代码如下 public class TestPay {public static void main(String[] args) {Payment wechatPay new BankCardPay();PayManager.pay(wechatPay);} }可以看到增加一种BankCardPay支付方式并未对PayManager类做修改因此对之前已经上线的功能没有影响。后续再增加其它支付方式比如京东支付、抖音支付等等都很容易扩展。 可能有些同学会说这样修改增加很多个类可读性还没有之前好确实如此有些情况下代码的扩展性会跟可读性相冲突比如上面我们重构代码之后可读性没有之前的if分支好所以很多时候我们要在扩展性和可读性之间做权衡在某些场景下代码的可读性很重要我们就牺牲一些扩展性在某些场景下代码的扩展性很重要我们就牺牲一些可读性。 比如上述的例子如果项目一开始就说我们的支付方式只支持Alipay和WechatPay这两种支付方式那刚开始的写法思路简单易读它就是合理的。相反如果后续要增加很多种支付方式那么我们重构之后的写法就是比较合理的因此是否合理没有一个统一的标准一定要结合业务需求、场景等来进行重构。 三、总结 1.定义 软件实体如类、模块和函数应该对扩展开放对修改关闭。 开闭原则并不是说完全杜绝修改而是以最小的修改代码的代码来完成新的功能开发低层模块的变更必然要有高层模块进行耦合否则就是一个独立无意义的代码片段。 2.为什么要使用开闭原则 (1)对于测试来讲新增的方法不会对已有的方法造成影响只需要保证新增的类、模块和函数是正确的就可以了 (2)提高可复用性在面向对象的设计中所有的逻辑都是从原子逻辑组合而来的而不是在一个类中独立实现一个业务逻辑。只有这样代码才可以复用粒度越小被复用的可能性就越大。 (3)提高可维护性从上述例子中可以看出来当对已有功能做修改时增加一个类即可这是不是就是维护人员很乐意干的事即增加一个类而不是修改一个类。 3.如何做到对扩展开放、对修改关闭 添加一个新的功能应该是通过在已有代码基础上扩展代码(新增模块、类、方法、属性等)而非修改已有代码(修改模块、类、方法、属性等)的方式来完成。我们要时刻具备扩展意识、抽象意识、封装意识在写代码的时候要多花点时间思考一下未来可能的变更以便在未来需求变更的时候在不改变代码整体结构的情况下将新的代码灵活的插入到项目中。 很多设计原则、设计思想、设计模式都是以提到代码的扩展性为最终目的。特别是23中经典设计模式大部分都是为了解决代码的扩展性而总结出来的都是以开闭原则为指导原则。最常用提高代码扩展性的方法有多态、依赖注入、基于接口而非实现编程以及大部分的设计模式(装饰、策略、模版、责任链、状态) 好了本篇博客就到这里了后续还会继续更新关于设计原则和设计模式相关的文章如果觉得对你有用帮忙点赞回复666 参考书籍 《设计模式之禅》 《架构整洁之道》