架构-设计模式
itegel84
做一个对社会有用的人
展开
-
【设计模式】状态
状态,应该大家都很熟,学过计算机的应该都知道状态机。状态实现比较简单,当然也比较灵活。写一个demo程序,测试一下而已,主要是状态和策略两个模式很相似,想体会一下其中的区别。状态一般也要求状态是一个单例,否则状态的生成和回收还是比较繁琐的。1. State.h:#include using namespace std;class Context;class State{原创 2013-05-20 12:31:42 · 616 阅读 · 0 评论 -
【设计模式】工厂方法
工厂方法,跟抽象工厂、建造者模式等解决的问题都类似,通过将产品和其实现分离,达到了客户和具体产品之间的解耦。工厂方法,其精髓就是他名字本身,在工厂类中提供一个工厂方法,该方法返回具体的产品。客户只需要关注该产品的接口(一般是抽象父类),而无需关注起具体实现和创建过程。工厂方法的一个缺点是客户可能仅仅为了穿件一个具体的产品,需要增加creator的一个子类。一般通过c++的模板方法可以解原创 2013-09-16 13:21:39 · 861 阅读 · 0 评论 -
【设计模式】原型模式
原型模式,如其名称,核心就是要实现一个原型类,该类支持clone操作,从而客户可以从原型克隆出具体的类。其效果主要有如下:可以动态增加和删除产品。这个就是通过clone代替new等操作,也避免了客户与具体类打交道。通过改变对象的值,指定新的对象。clone出一个新对象后可以修改其参数改变对象,如果参数较多,可以提供类似initialize方法。减少creator类,减少子类数目。客原创 2013-09-23 15:40:13 · 689 阅读 · 0 评论 -
【设计模式】单件
balabala估计很多人开始看设计模式的书或者初学时用得最多的都是单件了。就不多说了。不过小心滥用。这里单独那一个文章来写是因为,单件是创建型模式中最后一个。作为一个里程碑吧。创建型模型,用得最多的估计好似工厂方法。其他的可以认为是其一种衍生模式。后面继续结构性模式。原创 2013-09-23 18:58:42 · 537 阅读 · 0 评论 -
【设计模式】适配器
adapter,其实除了是一种软件设计模式,也是系统设计中经常碰到的思路。两个模块交互,有一个升级后接口变了,另一个还不想升级,这时候就需要一个适配模块,做个翻译的工作。总体思想比较简单。C++实现有两种,一种是类适配。通过公共继承目标类,私有继承被适配的类的多重继承来实现。因为本人对多重继承没什么好感,所以没写相关demo。另一种就是组合方式,适配器维护一个被适配的类的指针来实现。因原创 2014-03-19 17:15:35 · 824 阅读 · 0 评论 -
【设计模式】组合模式
组合模式(composite)主要用来解决树形层次结构对象模型。用统一的component对象屏蔽不同类型的子节点的差异。对于客户端来说都提供一个统一的接口。典型应用场景如菜单,文件树等。组合模式思想感觉跟递归有一些关系。将不同的items组合成一个composite,而不同的composite和叶子节点又能组合出新的composite。看起来该模式似乎还比较简单。但是也没想到更多的场原创 2014-04-02 11:26:32 · 499 阅读 · 0 评论 -
【设计模式】装饰
Decorator模式,可以不改变原有类,或者凡索的继承就可以改变其行为。不会破坏原有接口。我觉得decorator是最优雅的一个模式。设计模式中的小贵妇,小喜欢。还是那个经典的咖啡加牛奶,糖的问题。其实牛奶咖啡不是咖啡,也不是牛奶。只是一个组合体,所以用继承等来解决从概念上就有点说不通。何况还会带来乘积关系的子类膨胀。直接写代码吧: /** * @file test_de原创 2014-04-03 11:36:28 · 632 阅读 · 0 评论 -
【设计模式】门面
Facade(fe‘saad)模式,是一个没有固定l原创 2014-04-04 14:47:21 · 590 阅读 · 0 评论 -
【设计模式】桥
bridge模式据说是比较复杂的一个模式,从类图看其实一点都不复杂。我想复杂的部分应该就是怎么防止滥用吧。其主要思想是将一些经常变化实现部分与其表述分开。这样就表述和实现都可以独立变化了。这里想起了鸵鸟是不是鸟的一个问题。也不知道举得合不合适。主要还是写一些代码吧。仅供参考就好。现在对这块还没有更深入的理解。另外一个说bridge模式复杂的原因,我觉得主要是因为他应用的场景本身就复杂。原创 2014-03-26 16:14:20 · 460 阅读 · 0 评论 -
php wrapper实现
【背景】做一个thrift client的wrapper,用以实现对于服务器的重试逻辑。【主要的一些】原创 2014-08-26 18:45:07 · 1745 阅读 · 0 评论 -
【设计模式】建造者(生成器)
生成器模式,也叫建造者模式。有人说后者是想强调该模式重点是强调建造过程,而不是生成。个人比较认同,所以后文也叫建造者模式。建造者模式,主要意图是将对象的建造于他的表示分离。从而使得同样的建造过程可以建造出不同的产品。参与者有建造者,导演和具体的产品。举例说明,我们想生产电脑,电脑就是产品。声明一个类,叫builder,而具体的建造者,需要继承自这个父类,并实现其构造方法,并最终返回原创 2013-09-12 13:10:10 · 863 阅读 · 0 评论 -
【设计模式】备忘录
备忘录,其实名字也比较形象。我们经常遇到将一个类的状态恢复到历史版本的需求。比如一个记事本,想保存一个上N个状态,通过Ctrl+Z可以恢复此前编辑内容。备忘录就非常适合这种场景。此时发起者类,希望能够将自身状态保留在某处,而且不希望过多的暴露细节。为了上述目的,发起者会在某个时刻通过new出一个备忘类对象,并将该对象托管给管理者类。然后需要恢复状态时,又从管理者类中获取具体状态,将自身恢复到某原创 2013-06-08 15:41:28 · 875 阅读 · 0 评论 -
【设计模式】策略
P.S. 最近工作不是很忙,多写点东西吧。之前说过策略和状态从类图上看很像,但是应用场景很不同。状态是context自身的状态变迁(控制可以是在外边,也可以是在具体状态处理函数内)的场景下使用,不同状态对于客户是透明的;而策略,则是客户要求对于context采用不同的策略。这个策略对客户是暴露的。在策略模式用户指定采用哪个策略。当然这个指定可以是在编译时静态绑定(用模板那),也可以是在运行时动原创 2013-05-21 20:04:49 · 532 阅读 · 0 评论 -
【设计模式】观察者
观察者模式,用于多个对象关注同一个对象的变化的情况。王泽宾大牛写的文章比较生动,我只是用自己的理解实现了一个版本,而已。http://blog.csdn.net/wanghao72214/article/details/4017507一,经典一点的实现,当然subject应该有个get_state的虚接口比较正宗,为了简单就先这样吧:#include #include原创 2013-05-19 18:17:35 · 637 阅读 · 0 评论 -
【设计模式】访问者
Visitor模式,顾名思义,就是有客人要来拜访,当然客人不一定是谁,我们家也不一定就我一个人。所以是一个N:M的一个关系。但是我们家里的人一般都是比较固定的。就我跟我老婆,孩子,偶尔爸妈过来住一住。而来访者,可能是随便谁谁。他来我们家拜访,我肯定是要接待的。一般至少得开个门吧,然后我们还会开放一些空间给她参观,比如客厅,每个人都是可以参观的。而对于每个家庭成员,visitor可能要有不同原创 2013-05-23 10:45:54 · 573 阅读 · 0 评论 -
【设计模式】模板方法
Template方法模式,与c++的模板没有直接关系。或者可以认为这里的template是针对方法(函数)来说的,而c++的template则是针对成员变量或者参数来讲的。字面意思有一些关系。template method主要是通过在父类中定义一个模板,子类中实现该模板中的个性化部分。实现了固定部分和变化部分的解耦。模板方法本身比较简单。其目的就是为了共享一些公共部分,提升代码复用性。简单原创 2013-05-23 18:24:27 · 597 阅读 · 0 评论 -
【设计模式】命令
命令模式,最常应用的场景或许就是各种触发命令的场合。这个通过名称就可以联想,而且还比较容易理解。而其他诸如回调啊之类的应用场景目前还不是很能体会。命令模式目的用命令类本身将client和其真正实现者(receiver)进行解耦,从而用户只关心具体的命令,而不去关心其实现。而增加命令,对于现有的receiver和client都可以透明。而对于命令中的可撤销等感觉也不是必须的。增加这个特性原创 2013-05-27 19:36:58 · 552 阅读 · 0 评论 -
【设计模式】职责链
设计模式听起来挺神秘,看例子和实现又很简单,用起来却灵活多变,总叫人觉得没学到真正灵魂的东西。从今天起,一个一个模式的记录一下我自己的理解。因为时间问题,这部分可能会延续比较长的时间了。 职责链:顾名思义就是一个链表(实际上跟链表有本质区别)。职责链是为了解决请求和多个响应者之间的耦合。 先看一下UML描述吧:当前处理者,如果能够处理该请求,则处理之,否则将该请原创 2011-03-28 15:09:00 · 793 阅读 · 0 评论 -
【设计模式】解释器
解释器,似乎应用场景比较固定:解析某种文法(比如正则表达式,编程语言)。实际中应用可能不会很多,先拿来了解一下。肯定是理解还不够深入。所没能真正体会其奥妙。该模式由上下文、表达式和客户组成。表达式又分为终结节点和非终结节点组成。这种结构天然的会想到用递归。所以性能肯定不是很理想。当然在设计模式那边书里也说了该模式应用场景就是对性能没有严苛的要求的场景。终结节点,负责解析该节点处的行为,原创 2013-05-30 19:04:22 · 887 阅读 · 0 评论 -
【设计模式】迭代器
迭代器,应该都不陌生了,STL就有提供。迭代器模式,就是为了对于聚合对象做遍历用,从而隔离具体聚合对象和其访问者。访问者不需要知道聚合对象内部实现,也可以不用跟直接跟聚合对象打交道。对于不同的聚合对象,一般都用统一的接口(多态迭代),从而方便使用者。迭代器的实现相对也比较简单,但是有一些重复读,跳读等问题。这个后面在研究研究。/***************************原创 2013-05-31 11:59:36 · 578 阅读 · 0 评论 -
【设计模式】中介者
中介者,说白了跟市面上黑中介类似。当然这个中介,开发者是可以控制其行为的。也是在一定的信任关系上建立的。该模式要解决的问题是,一堆对象之间交叉耦合问题。网上看过群聊的例子。如果没有任何一个平台,多人之间的会话会是什么样的呢?不举多人,就三个吧A想把一句话说给BC,那么他首先要知道B和C在哪儿,然后分别告诉对方,自己想说的事情。如果再加一个人呢?问题很明显,此时各种群聊工具应运而生。我写原创 2013-06-05 19:33:37 · 865 阅读 · 0 评论 -
异步编程几种模式
callback事件监听pub/subpromise消息队列是典型的pub/sub模式实现,典型的如kafka。回调是最原始的。事件驱动这个对于GUI或JS这些里很常见。promise是把callback等顺序化,可以更直观的维护各种回调逻辑。可能有偏见,暂时没看到有啥特别之处,当然也是因为没有用过。回调可能会失败,失败时候就需要重试。重试策略怎么维原创 2016-05-19 15:29:26 · 970 阅读 · 0 评论