![](https://img-blog.csdnimg.cn/20201014180756928.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
c艹设计模式
文章平均质量分 76
无情の学习机器
追风赶月莫停留,平芜尽处是春山
展开
-
设计模式——领域规则类及其经典案例
领域规则类再特定领域中,某些变化虽然频繁,但是可以抽象为某种规则,这个时候只需要结合特定领域,将问题抽象为语法规则,从而给出改领域下的一般性解决方案。典型模式:interpreterinterpreter就这一种动机就不说了,跟上面一样。比如说我们想实现一个加减运算: string expstr = "a+b-c+d";我们可以提取出一种语法规则如下:首先我们写一个变量表达式类,先写一个接口class expression{public: virtual int interpr原创 2021-04-07 20:50:11 · 324 阅读 · 0 评论 -
设计模式——行为变化类及其经典案例
在组件构建过程中,组件行为的变化常常导致组件本身剧烈的变化,行为变化模式将组件的行为和组件本身进行解耦从而支持组件行为的变化,实现两者间的松耦合。典型模式:commandvisitorcommand(命令模式)在软件构建过程中,行为请求者和实现者通常是一种紧耦合的关系,但是某些场合比如需要对行为进行记录,撤销,重做等事务的时候,这种无法抵御变化的紧耦合是不合适的。command模式可以将请求封装成对象,从而可以用不同的请求对客户进行参数化,对请求排队或者记录,从而支持可撤销操作。#includ原创 2021-04-07 19:11:32 · 466 阅读 · 0 评论 -
设计模式——数据结构类及其经典案例
数据结构类设计模式常常有一些组件在内部具有特殊的数据结构,如果让用户程序依赖这些特定的结构,将极大地破坏组件的复用性。这个时候将这些特定数据结构封装在内部,在外部提供统一的接口来实现与特定结构无关的访问,是一种行之有效的解决方案。经典结构:compositeiteratorchain of responsibilitycomposite(组成模式)为了以树形结构表现出部分整体的关系,composite使得用户对单个对象和组合对象的使用具有一致性;#include<algorithm&g原创 2021-04-07 16:22:53 · 339 阅读 · 0 评论 -
设计模式——状态变化及其经典案例
状态变化类设计模式在组件构建过程中,某些对象的状态经常面临临时变化,如何对这些变化进行有效的管理,同时又维持高层模块的稳定,状态变化类设计模式为此问题提供了一种解决方案。经典模式:statemementostate (状态模式)动机:在软件构建过程中,某些对象状态发生改变,那么其行为也会发生改变,那么我们如何根据对象的状态透明地更改对象的行为,而不会为对象操作和状态转化之间引入紧耦合?上代码enum networkstate{ net_open, net_close, net_con原创 2021-04-06 19:29:07 · 234 阅读 · 0 评论 -
设计模式——接口隔离类及经典案例
接口隔离类设计模式在组件构建过程中,某些接口之间的直接的一来往往会带来很多问题,甚至根本无法实现。采用添加一层间接接口,来隔离相互紧密耦合的接口是一种常见的解决方案。经典模式如下:FacadeProxyAdapterMediatorFacade(门面模式)动机,如下图所示,就是为了简化外部和系统内部交互接口的方式,可以复用举个例子,大家买股票,每支股票可以看成是SubSystem,我们可以同时买多只股票,那么你需要知道多个SubSystem。有些人比较懒,不想关注股票,但是又想赚钱,那就原创 2021-04-06 16:58:27 · 239 阅读 · 0 评论 -
设计模式——性能问题及其经典案例
性能问题面对对象编程部很好解决了抽象接口的问题,但是不可避免要付出一定代价,也就是内存空间消耗,通常情况这种代价都可以忽略不计,但是在某些时候这种代价必须谨慎处理。典型模式:SingletonFlyweightSingleton(单例模式)动机:在软件设计过程中,有一些特殊有的类,在软件运行过程中只允许存在一个实例,以保证逻辑正确和良好的效率。作为设计者,那么如何保证使用者在使用过程中绕过常规的构造器实现一种机制来保证一个实例。上代码:class singleton{private:原创 2021-04-04 17:46:39 · 201 阅读 · 0 评论 -
设计模式——对象创建类及经典案例
对象创建类设计模式通过对象创建绕开new,来避免创建过程中的紧耦合,从而支持对象创建的稳定,它是接口抽象后的第一步工作。典型模式:factory methodabstract factoryprototypebuilderfactory method动机:在软件系统中,经常面临着创建对象的工作,由于需求的变化,需要创建的对象的具体类型也经常变化。...原创 2021-04-03 21:23:00 · 234 阅读 · 1 评论 -
设计模式——单一职责类及经典案例
单一职责类设计模式再软件设计过程中,如果责任划分不清晰,使得继承得到的结果往往是随着需求变化, 子类急剧膨胀,同时充斥着重复的代码,这个时候的关键是划清责任;典型模式:DecoratorBridgeDecorator动机:在某些情况下,会过度的使用继承来拓展对象功能,由于继承为类型引入静态特质,这种拓展方式缺乏灵活性,并且随着子类的增多,各种子类的组合会导致更多的子类膨胀//业务操作class mystream{public: virtual char* Read(const int原创 2021-04-01 18:19:22 · 300 阅读 · 0 评论 -
设计模式——组件协作类及经典案例
组件协作类设计模式组件协作通过地址晚绑定,实现了框架与应用之间的松耦合。template method发生场景:对于某一项任务,常常有稳定的操作股价,但是子步骤却需要很多改变的需求,或者由于固有的原因无法和整体结构同时实现,必须一早一晚。原代码:// An highlighted block#include<iostream>#include<functional>using namespace std;using namespace placeholders;原创 2021-03-30 14:26:50 · 247 阅读 · 0 评论 -
设计模式 预备知识
设计模式笔记—— 预备知识请各位至少熟读c艹primer再来看1.重新理解面向对象隔离变化:抵御软件变化带来新变化的一种构建模式各司其职:新需求导致的变化不应该影响原类型的实现对象是什么:封装了代码和数据,是一种公共接口,也是有责任的抽象,也就是说接口一样,实现不一样2.原则原则比模式更重要,所有的设计模式都是依赖原则推导出来的,建议全文背诵依赖倒置原则(DIP):高层模块不应该依赖底层模块,二者都应该依赖于抽象,抽象不应该依赖于实现细节,实现细节应该依赖于抽象。开放封闭原则(OCP):原创 2021-03-24 16:07:29 · 114 阅读 · 0 评论