设计模式
文章平均质量分 84
沙diao网友
我不缺对象,我有new
展开
-
【设计模式】总结
总结 管理变化,提高服用 两个手段: 分解vs抽象 梨、香蕉、苹果---->水果 八大原则: 依赖倒置原则(DIP) 开放封闭原则(OCP) 单一职责原则(SRP) Liskov替换原则(LSP) 接口隔离原则(ISP) 对象组合优于类继承 封装变化点 面向接口编程 重构技法: 静态→动态 早绑定→晚绑定 继承→组合 编译时依赖→>运行时依赖 紧耦合→>松耦合 红色部分不常用 几乎所有的模式都属于第三种 继承和组合的内存模型是一样的 classA内存的前一部分都是B原创 2021-05-13 21:10:44 · 95 阅读 · 0 评论 -
【设计模式】领域规则模式(解析器)
领域规则模式 在特定的领域中,某些变化虽然频繁,但可以抽象为某种规则。这时候,结合特定领域,将问题抽象为语法规则,从而给出在该领域下的一般性解决方案 解析器interpretor 1.解析器interpretor 动机: 在软件构建过程中,如果某一特定领域的问题比较复杂,类似的结构不断重复出现,如果使用普通的编程方式来实现将面临非常频繁的变化 在这种情况下,将特定领域的问题表达为某种语法规则下的句子 然后构建一个解释器来解释这样的句子,从而达到解决问题的目的 比如a+b-c+d : //语法树 #i原创 2021-05-13 19:30:48 · 215 阅读 · 1 评论 -
【设计模式】行为变化模式(命令/访问者)
行为变化模式 在组件的构建过程中,组件行为的变化经常导致组件本身剧烈的变化。行为变化模式将组件的行为和组件本身进行解耦,从而支持组件行为的变化,实现两者之间的松耦合 命令模式command 访问者模式visitor 1.命令模式command 动机: 在软件构建过程中,行为请求者与行为实现者通常呈现一种紧耦合。但在某些情况下——比如需要对行为进行记录、撤销/重(undo/redo)、事务等处理,这种无法抵御变化的紧耦合是不合适的 在这种情况下,如何将行为请求者与行为实现者解耦?将一组行为抽象为对象,可原创 2021-05-13 17:36:57 · 241 阅读 · 0 评论 -
【设计模式】数据结构模式(组合/迭代器/责任链)
数据结构模式 常常有一些组件在内部具有特定的数据结构,如果让客户程序依赖这些特定的数据结构,将极大地破坏组件地复用。这时候,将这些特定数据结构封装在内部,在外部提供统一地接口,来实现与特定数据结构无关地访问,是一种行之有效地解救方案 组合模式Composite 迭代器Iterator 责任链Chain of Responsibility 1.组合模式Composite 动机: 在软件在某些情况下,客户代码过多地依赖于对象容器复杂地内部实现结构,对象容器内部实现结构(而非抽象接口)的变化将引起客户代码的频原创 2021-05-11 16:36:39 · 189 阅读 · 0 评论 -
【设计模式】状态变化模式(状态/备忘录)
状态变化模式 在组件构建过程中,某些对象的状态经常面临变化,如何对这些变化进行有效的管理?同时又维持高层模块的稳定?“状态变化"模式为这一问题提供了一种解决方案。 状态模式State 备忘录Memento 1.状态模式state 动机: 在软件构建过程中,某些对象的状态如果改变,其行为也会随之而发生改变,比如文档处于只读状态,其支持的行为和读写状态支持的行为就可能完全不同。 如何在运行时根据对象的状态来透明地更改对象地行为?而不会为对象地操作和状态转化之间引入紧耦合? //网络应用 对应网络地三种状态原创 2021-05-11 10:19:57 · 130 阅读 · 0 评论 -
【设计模式】接口隔离模式(门面/代理/适配器/中介者)
接口隔离模式 在组建地构建过程中,某些接口之间直接地依赖常常会到来很多问题、甚至根本无法实现。采用添加一层间接(稳定)接口,来隔离本来互相紧密关联地接口是一种常见地解决方案 操作系统就是软件和硬件之间地间接层 操作系统地提出就是变化和稳定地剥离 将硬件和软件间稳定地部分剥离出来成为操作系统 软件设计的思想核心关键词就是间接indirection 门面模式Facade 策略模式Proxy 适配器Adapter 中介者Mediator 1.门面模式Facade 动机: 上述A方案的问题在于组件的客户和组原创 2021-05-10 18:37:28 · 200 阅读 · 0 评论 -
【设计模式】对象性能模式(单例/享元)
对象性能模式 面向对象很好的解决了抽象的问题,但是不可避免地要付出一定地代价。(比如虚函数 需要内存)对于通常情况下,面向对象地成本大都可以忽略不计。但是某些情况下,面向对象所带来地成本需要谨慎处理。 解决的不是抽象性的问题,解决的是代价问题 单例模式Singleton 享元模式Flyweight 1.单例模式Singleton 动机: 在软件系统中,经常有这样地一些特殊地类,必须保证它们在系统中只存在一个实例,才能确保它们地逻辑正确性、以及良好地效率 如何绕过常规地构造器,提供一种机制来保证一个类只有原创 2021-05-10 10:32:08 · 128 阅读 · 0 评论 -
【设计模式】对象创建模式(工厂/抽象工厂/原型/构造器)
对象创建模式 通过对象创建模式绕开new,来避免对象创建过程中所导致的紧耦合(依赖具体类)从而支持对象创建的稳定。它是接口抽象之后的第一步工作。 工厂方法Factory Method 抽象工厂Abstract Factory 原型模式Prototype 构造器Builder 1.工厂方法Factory Method 动机: 在软件系统中经常面临着创建对象的工作,由于需求的变化,需要创建的对象的具体类型经常变化 如何应对这种变化?如何绕过常规的对象创建方法 new,提供一种封装机制来避免客户程序和这种具体转载 2021-05-08 17:07:58 · 131 阅读 · 0 评论 -
【设计模式】单一职责模式(装饰模式/桥模式)
单一职责模式 在软件组件的设计中,如果责任划分不清晰,使用继承得到的结果往往是随着需求的变化,子类急剧膨胀,同时充斥着重复代码,这时候的关键是划清责任 bad simie——代码大量重复 下面两种模式在责任划分方面尤为突出(其他的模式也是有职责划分问题的) 装饰模式Decorator 桥模式Bridge 1.装饰模式Decorator 动机: 在某些情况下过度的使用继承来扩展对象的功能,由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功转载 2021-05-07 15:07:07 · 115 阅读 · 0 评论 -
【设计模式】组件协作模式(模板方法/策略模式/观察者模式)
组件协作模式 现代软件:框架与应用的划分 组件协作主要通过晚绑定来实现松耦合 template method模板方法 strategy策略模式 observer/event观察者模式 1.模板方法template method 样板 动机:软件构件过程中对于某一项特定的任务常常有稳定的整体结构,但各个子步骤却有很多变化,先实现谁呢?如何在确定的整体结构的前提下来灵活应对各个子步骤的变化或晚期实现需求呢? //程序库开发人员 class Library{ public: void Step1(){原创 2021-05-07 12:30:58 · 163 阅读 · 0 评论 -
【设计模式】设计模式概述
视频参照https://www.bilibili.com/video/BV1V5411w7qg?p=1 资料https://github.com/19PDP/Bilibili-plus/tree/master/C%2B%2B-DesignPattern 一.概述 每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次一次的使用该方案而不必做重复劳动。 《设计模式:可复用面向对象软件的基础》 该书有四人编写 gang of four——GOF 软件设计复杂的原因原创 2021-05-07 12:26:32 · 188 阅读 · 0 评论