开闭原则

设计模式4-开放封闭原则

怎甘沉沦 提交于 2020-02-06 12:43:08
2. 开放封闭原则 2.1 描述 可以增加功能,但是不修改已有的代码。所有他由两层含义,开发和封闭。 2.3 优点 1) 封闭原则提高代码稳定行,不修改已有的代码,减少系统功能的影响,减少功能的测试性。 2)开放原则提高复用性,开放原则需要考虑功能扩展。 3) 开放封闭能够降低需求变化带来的不良影响 2.4 实现方法 1) 封闭不变的 提取抽象层,封装接口。一个稳定的接口很重要。 2) 开放变化的 通过多态继承等方法,将变化的在实现类中修改。 来源: CSDN 作者: Mr-Dong 链接: https://blog.csdn.net/qq_29067097/article/details/104193556

STM32单片机程序与6个设计原则之开闭原则

 ̄綄美尐妖づ 提交于 2020-02-06 08:17:20
片头 在上一篇文章中已经介绍了“单一职责原则”在单片机程序中的使用,并以“环形缓存”作为介绍切入点,因为“环形缓存”在应用中比较多,所以在介绍“开闭原则”时依然以它作为介绍切入点。 六个设计原则分别是:A、单一职责原则;B、开闭原则;C、里氏替换原则;D、最少知识原则;E、接口隔离原则;F、依赖倒置原则;G、激活原则; 以上有7个,最后一个是我加上去的,此文主要介绍第二个设计原则:开闭原则在设计STM32单片机软件的应用。 正文 定义:开闭原则表示打开拓展的大门,关闭修改的大门。 要做的“开闭原则”首要任意就是解决(确定)范围,即开闭原则的软件单位。那么在单片机软件开发中的职责单一的软件单位是什么呢?是一个函数,一个结构体,一个枚举定义,一个软件模块(XXX.c与XXX.h)。 首先以一个电路图说明“开闭原则”的例子(在此假设读者具备一定原理图知识)背景假设:此图是一个智能锁的原理图,目前此图版本:V7.0。如下图所示: 由于市场需求需要增加人体识别PIR传感器,需要对V7.0版原理图 “更新”。现在有以下两种更新方案,如下图所示: 以上两种方案,一个调整了原来的信号定义,一个不改变原来信号定义。哪个方案优哪种方案劣?从版本后看:现在到了8.0版,可见之前有很多个版本,需要考虑的情况很多。假设现在V8.0版已经是这个“智能锁”产品的第10个年头了。之前V1.0还有库存吗

GOF23种设计模式(Design Pattern)总结

大兔子大兔子 提交于 2020-02-06 01:26:43
比较 设计模式 常用程度 适用层次 引入时机 结构复杂度 Abstract Factory 比较常用 应用级 设计时 比较复杂 Builder 一般 代码级 编码时 一般 Factory Method 很常用 代码级 编码时 简单 Prototype 不太常用 应用级 编码时、重构时 比较简单 Singleton 很常用 代码级、应用级 设计时、编码时 简单 Adapter 一般 代码级 重构时 一般 Bridge 一般 代码级 设计时、编码时 一般 Composite 比较常用 代码级 编码时、重构时 比较复杂 Decorator 一般 代码级 重构时 比较复杂 Facade 很常用 应用级、构架级 设计时、编码时 简单 Flyweight 不太常用 代码级、应用级 设计时 一般 Proxy 比较常用 应用级、构架级 设计时、编码时 简单 Chain of Resp. 不太常用 应用级、构架级 设计时、编码时 比较复杂 Command 比较常用 应用级 设计时、编码时 比较简单 Interpreter 不太常用 应用级 设计时 比较复杂 Iterator 一般 代码级、应用级 编码时、重构时 比较简单 Mediator 一般 应用级、构架级 编码时、重构时 一般 Memento 一般 代码级 编码时 比较简单 Observer 比较常用 应用级、构架级 设计时、编码时 比较简单

设计模式七大原则之开闭原则

两盒软妹~` 提交于 2020-02-02 03:02:03
OCP(Open Close Principle) 开闭原则是编程中最基础、最重要的设计原则。编程中遵循其他原则,以及使用设计模式的目的就是使程序符合开闭原则。 一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方)。用抽象构建框架,用实现扩展细节。 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。 应用示例 不满足OCP的代码 如下是一个实现画图功能的程序类图及代码 package com . atguigu . principle . ocp ; public class Ocp { public static void main ( String [ ] args ) { //使用看看存在的问题 GraphicEditor graphicEditor = new GraphicEditor ( ) ; graphicEditor . drawShape ( new Rectangle ( ) ) ; graphicEditor . drawShape ( new Circle ( ) ) ; graphicEditor . drawShape ( new Triangle ( ) ) ; } } //这是一个用于绘图的类 [使用方] class GraphicEditor { //接收Shape对象

面向对象设计原则之开闭原则

扶醉桌前 提交于 2020-01-28 00:41:43
两截门--一个被水平分割为两部分的门,这样每一部分都可以独立保持开放或封闭 开放-封闭原则(The Open-Closed Principle) 软件实体(类、模块、函数)应该是可以扩展的,但是不可以修改的。 如果程序中的一处改动就会产生连锁反应,导致一系列的相关模块的改动,那么设计就具有僵化的臭味。如果正确的应用OCP, 那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码。 描述 主要两个特征: “对于扩展是开放的” 模块的行为是可以扩展的,当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为。简言之,我们可以改变模块的功能。 “对于更改是封闭的” 对模块进行扩展时,不必改动模块的源代码。 关键是抽象 下图展示了一个简单的不遵循OCP的设计。Client类和Server类都是具体类,Client类使用Server类。如果我们希望Client对象使用另外一个不同的服务器对象,那么就必须要把Client类中使用Server类的地方更改为新的服务器类 下图是根据OCP设计重构的设计 ClientInterface类是一个拥有抽象成员函数的抽象类,Client类使用这个抽象类。如果我们希望Client对象使用一个不同的服务器类,那么只需要冲ClientInterface类派生一个新的类,无需对Client类做任何改动。 Shape应用程序

架构层级的“开闭原则”1

拈花ヽ惹草 提交于 2020-01-19 02:17:04
在类的层级,开闭原则(the-Open-Closed-Principle,简称OCP原则)的含义是:一个类对扩展是“开”放的,而对变更是封“闭”的,意思是说,应该在不改变类的前提下扩展一个类的行为。而通常的方式是继承和多态。 在架构层级,我们并不会变更系统的一部分功能(可能是最适用于当前架构的进程,守护进程,服务,或者微服务),而是通过新增功能的方式来复用已完成的代码。为了不对现有的部分做出变更,系统需要做到完全的解耦。接下来的内容将聚焦于事件驱动系统,并以消息队列实现服务间通信。消息队列 可以是ActiveMQ, RabbitMQ, ZeroMQ, Kafka或者其他服务,我将以Kafka的话语体系来进行描述,如主题(Topic),发布者,订阅者,以及类似Kafka的多个订阅者共享相同主题的能力。 一、消息系统 上图是一个一般用例:发布者向主题发布消息(或者事件),多个订阅者可以从主题处获得该事件。箭头指示了通信的流向。假定发布者和订阅者都是微服务的话,双层的圆角矩形代表某一特定微服务的多个实例。在本例中的四个微服务:发布者,订阅者1,订阅者2,订阅者n,每个微服务都有多个实例。 二、具体示例 举一个具体的例子。假设我们在一家汽车租赁公司工作,并负责建立一个车辆的可用性系统。整个租赁流程的简化视图如下: 第1步,车辆租赁:包含租赁协议的签订和客户选车的过程。随即可用的车辆数减1。

day12

你离开我真会死。 提交于 2020-01-09 14:21:10
1 1. 三合一 2 2. 当天练习独立完成 3 3. 指出案例中蕴含的理论: 4 (1)手雷爆炸 5 封装:手雷,玩家类,敌人类 6 继承:受害者 隔离 玩家类,敌人类与手雷 7 多态:玩家类,敌人类 重写 受害者的受伤方法 8 开闭原则:增加新的受害者,不影响手雷类 9 依赖倒置:手雷类调用受害者,而不调用玩家,敌人 10 11 (2)图形管理器 12 封装:图形管理器类,圆形类,矩形类 13 继承:图形类 隔离 圆形类,矩形类与图形管理器 14 多态:圆形类 矩形类 不影响图形管理类 15 开闭原则:添加新的图形,不影响图形管理器 16 依赖倒置:图形管理器调用图形类,不调用圆形类,矩形类 17 18 1. 老张开车去东北 19 封装:人类,汽车类,飞机类 20 继承:交通工具 隔离 汽车类,飞机类与人类。 21 多态:汽车类、飞机类 重写 交通工具的运输方法. 22 开闭原则:增加新的交通工具,不影响人类. 23 依赖倒置:人类调用交通工具,而不调用汽车、飞机. 24 25 4. (扩展)根据信息管理系统(MVC),完成购物车(MVC)。 26 5. 穷尽一切手段,在互联网上搜索面向对象三大特征相关资料. 27 结合课堂所讲,总结心得体会下来。 # demo01""" 继承 -- 语法 财产:钱不用孩子挣,但是可以花. 皇位:江山不用孩子打,但是可以坐. 代码:子类不用写

面向对象设计原则之开闭原则

﹥>﹥吖頭↗ 提交于 2020-01-01 02:34:31
开闭原则是面向对象的可复用设计的第一块基石,它是最重要的面向对象设计原则。开闭原则由 Bertrand Meyer 于1988年提出,其定义如下: 开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。 在开闭原则的定义中, 软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类 。 任何软件都需要面临一个很重要的问题,即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时,我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则,那么可以非常方便地对系统进行扩展,而且在扩展时无须修改现有代码,使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大,软件寿命越来越长,软件维护成本越来越高,设计满足开闭原则的软件系统也变得越来越重要。 为了满足开闭原则,需要对系统进行抽象化设计, 抽象化是开闭原则的关键 。在Java、C#等编程语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制,可以通过它们定义系统的抽象层,再通过具体类来进行扩展。如果需要修改系统的行为,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可

设计模式-开闭原则

流过昼夜 提交于 2019-12-30 11:51:09
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>   今天我们聊设计模式中的开闭原则,即“一个软件实体应当对扩展开放,对修改关闭。即软件 实体应尽量在不修改原有代码的情况下进行扩展。”,不修改原有的代码就是新增类。我以配置数据源为例,假设我们有两个数据源,未来还可能新增一个数据源,我们应当如何写配置类呢? 1.写抽象配置类 @Data public abstract class AbstractDataSource { private String url; private String username; private String password; private String driverClassName; public DataSource createDataSource() { DruidDataSource druidDataSource = new DruidDataSource(); druidDataSource.setDriverClassName(getDriverClassName()); druidDataSource.setUrl(getUrl()); druidDataSource.setUsername(getUsername()); druidDataSource.setPassword(getPassword());

面向对象原则之开闭原则

跟風遠走 提交于 2019-12-20 10:29:00
开闭原则 基本介绍 开闭原则(Open-Closed Principle, OCP),是面向对象的可复用设计的第一块基石,它是最重要的面向对象设计原则,是由 Bertrand Meyer于1988年提出 ,意为一个软件实体应当 对扩展开放,对修改关闭 。即软件实体应尽量在不修改原有代码的情况下进行扩展。 任何软件系统都需要面临一个很重要的问题,即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时,我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则,那么可以非常方便地对系统进行扩展,而且在扩展时无须修改现有代码,使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延展性。随着软件规模越来越大,软件寿命越来越长,软件维护成本越来越高,设计满足开闭原则的软件系统也变得越来越重要。 为了满足开闭原则,需要对系统进行抽象化设计,抽象化是开闭原则的关键。在Java编程语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为移至具体的实现层中完成。如果需要修改系统的行为,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。 代码示例 下面是一个未经重构的计算机器类: public class CalculatorUtils { /** * 计算 * * @param