软件架构设计原则之开闭原则

简介: 开闭原则(Open-Closed Principle,OCP)是指一个软件实体(如类、模块和函数)应该对扩展开放,对修改关闭。所谓的开闭,也正是对扩展和修改两个行为的一个原则。它强调的是用抽象构建框架,用实现扩展细节,可以提高软件系统的可复用性及可维护性。开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定、灵活的系统。例如版本更新,我们尽可能不修改源代码,但是可以增加新功能。

开闭原则(Open-Closed Principle,OCP)是指一个软件实体(如类、模块和函数)应该对扩展开放,对修改关闭。所谓的开闭,也正是对扩展和修改两个行为的一个原则。它强调的是用抽象构建框架,用实现扩展细节,可以提高软件系统的可复用性及可维护性。开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定、灵活的系统。例如版本更新,我们尽可能不修改源代码,但是可以增加新功能。

在现实生活中开闭原则也有体现。比如,很多互联网公司都实行弹性作息时间,只规定每天工作8小时。意思就是说,对于每天工作8小时这个规定是关闭的,但是你什么时候来、什么时候走是开放的。早来早走,晚来晚走。

开闭原则的核心思想就是面向抽象编程,接下来我们来看一段代码。

以咕泡学院的课程体系为例,首先创建一个课程接口ICourse:

public interface ICourse {
    Integer getId();
    String getName();
    Double getPrice();
}

整个课程生态有Java架构、大数据、人工智能、前端、软件测试等,我们来创建一个Java架构课程的类JavaCourse:

public class JavaCourse implements ICourse{
    private Integer Id;
    private String name;
    private Double price;
    public JavaCourse(Integer id, String name, Double price) {
        this.Id = id;
        this.name = name;
        this.price = price;
    }
    public Integer getId() {
        return this.Id;
    }
    public String getName() {
        return this.name;
    }
    public Double getPrice() {
        return this.price;
    }
}

现在我们要给Java架构课程做活动,价格优惠。如果修改JavaCourse中的getPrice()方法,则存在一定的风险,可能影响其他地方的调用结果。我们如何在不修改原有代码的前提前下,实现价格优惠这个功能呢?现在,我们再写一个处理优惠逻辑的类JavaDiscountCourse(思考一下为什么要叫JavaDiscountCourse,而不叫DiscountCourse):

public class JavaDiscountCourse extends JavaCourse {
    public JavaDiscountCourse(Integer id, String name, Double price) {
        super(id, name, price);
    }
    public Double getOriginPrice(){
        return super.getPrice();
    }
    public Double getPrice(){
        return super.getPrice() * 0.61;
    }
}

回顾一下,简单看一下类结构图,如下图所示。

466cc680480b869a39034d8abed89e0f.png


本文为“Tom弹架构”原创,转载请注明出处。技术在于分享,我分享我快乐!  

如果本文对您有帮助,欢迎关注和点赞;如果您有任何建议也可留言评论或私信,您的支持是我坚持创作的动力。


【推荐】Tom弹架构:30个设计模式真实案例,挑战年薪60W不是梦

本文节选自《设计模式就该这样学》本文自2012年10月29日起持续连载,请大家持续关注....序言Design Patterns: Elements of Reusable Object-Oriented Software(以下简称《设计模式》),一书由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides合著(Addison-Wesley,1995)。这四位作者常被称为“四人组(Gang of Four)”,而这本书也就被称为“四人组(或 .

https://blog.csdn.net/gupaoedu_tom/article/details/121042618


其他设计原则


Tom弹架构:依赖倒置原则(Dependence Inversion Principle,DIP)https://blog.csdn.net/gupaoedu_tom/article/details/120905135


Tom弹架构:单一职责(Simple Responsibility Pinciple,SRP)https://blog.csdn.net/gupaoedu_tom/article/details/120906842


Tom弹架构:接口隔离原则(Interface Segregation Principle, ISP)https://blog.csdn.net/gupaoedu_tom/article/details/120907031


Tom弹架构:迪米特原则(Law of Demeter LoD)https://blog.csdn.net/gupaoedu_tom/article/details/120907187


Tom弹架构:里氏替换原则(Liskov Substitution Principle,LSP)https://blog.csdn.net/gupaoedu_tom/article/details/120907389


Tom弹架构:合成复用原则(Composite/Aggregate Reuse Principle,CARP)https://blog.csdn.net/gupaoedu_tom/article/details/120907563

相关文章
|
5天前
|
消息中间件 监控 API
深入浅出微服务架构设计原则
在软件开发的宇宙中,微服务如星辰般璀璨,引领着分布式系统的航向。本文将带你穿梭于微服务的星系,探索其背后的设计哲学与实践精髓,从服务边界的划分到数据一致性的保障,再到服务的通信与协作,我们将一同揭开微服务架构高效、可扩展且灵活的秘密。
15 4
|
6天前
|
消息中间件 设计模式 API
后端开发中的微服务架构设计原则
【8月更文挑战第13天】在软件工程的世界中,微服务架构已经成为一种流行的设计模式,它通过将复杂的应用程序分解成一组小的服务来简化开发和部署。本文探讨了微服务背后的设计理念,以及如何在后端开发实践中应用这些原则来构建可扩展、灵活且易于维护的系统。我们将深入讨论服务的划分、通信协议的选择、数据一致性的保障以及容错性策略的实施,旨在为后端开发人员提供一套实用的微服务架构设计指导。
18 1
|
3月前
|
数据中心 网络架构 Python
【计算巢】数据中心的网络架构设计原则
【5月更文挑战第31天】探讨数据中心网络架构设计原则:稳定性是基础,需抵御各种挑战;强调扩展性,适应业务发展;追求高效,确保数据传输速度;注重灵活性,灵活应对变化。简单Python代码示例展示网络节点连接。设计时需具备长远眼光,综合考虑技术方案,以构建坚固高效的信息桥梁。同学们,要持续学习和探索,为信息世界贡献力量!
50 2
|
3月前
|
监控 安全 API
微服务架构下的API网关设计原则
【5月更文挑战第31天】在本文中,我们将深入探讨微服务架构下API网关的设计原则。API网关作为微服务架构的入口点,其设计至关重要。我们将从性能、安全性、可扩展性等方面进行分析,并提出一些实用的设计建议。
|
3月前
|
存储 缓存 运维
云计算架构设计原则
【4月更文挑战第6天】这篇文章介绍了基于云计算的架构设计六大原则:合理部署、业务持续、弹性扩展、性能效率、安全合规和持续运营。
|
12月前
|
设计模式 关系型数据库 数据安全/隐私保护
软件架构设计原则之单一职责原则
单一职责(Simple Responsibility Pinciple,SRP)是指不要存在多于一个导致类变更的原因。假设我们有一个类负责两个职责,一旦发生需求变更,修改其中一个职责的逻辑代码,有可能导致另一个职责的功能发生故障。这样一来,这个类就存在两个导致类变更的原因。如何解决这个问题呢?将两个职责用两个类来实现,进行解耦。后期需求变更维护互不影响。这样的设计,可以降低类的复杂度,提高类的可读性,提高系统的可维护性,降低变更引起的风险。总体来说,就是一个类、接口或方法只负责一项职责。
92 0
软件架构设计原则之单一职责原则
|
12月前
|
设计模式 人工智能 Java
软件架构设计原则之依赖倒置原则
依赖倒置原则(Dependence Inversion Principle,DIP)是指设计代码结构时,高层模块不应该依赖低层模块,二者都应该依赖其抽象。抽象不应该依赖细节,细节应该依赖抽象。通过依赖倒置,可以减少类与类之间的耦合性,提高系统的稳定性,提高代码的可读性和可维护性,并且能够降低修改程序所造成的风险。接下来看一个案例,还是以Course(课程)为例,先来创建一个类Tom:
75 0
|
3月前
|
存储 关系型数据库 uml
00003.七大软件架构设计原则
00003.七大软件架构设计原则
56 0
|
12月前
|
设计模式 关系型数据库
软件架构设计原则之迪米特法则
迪米特原则(Law of Demeter LoD)是指一个对象应该对其他对象保持最少的了解,又叫最少知道原则(Least Knowledge Principle,LKP),尽量降低类与类之间的耦合度。迪米特原则主要强调:只和朋友交流,不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称为成员朋友类,而出现在方法体内部的类不属于朋友类。
91 1
|
11月前
|
开发者
构建可持续性软件架构:六大设计原则
构建可持续性软件架构:六大设计原则
225 0