dasgk的专栏

为了提高内聚和松耦合，我们经常会抽象出一些公共的接口形成抽象基类或者接口，然后我们可以通过声明一个指向基类的指针来指向实际的子类来实现，这样就达到了多态的目的，这样就出现了一个基类拥有众多子类的问题，当我们需要这个接口时，但却不知道要实例化哪个子类（因为接口或者抽象类是不能被实例化的）所以工厂模式就应运而生，它主要解决两个问题1.定义创建接口的对象，封装了对象的创建2.使得类的具体

看了下，Strategy模式，很是安慰，觉得该模式不用脑子去记了，因为这个模式跟Bridge模式好像是一样的，至少这两个在接收指针对象上的区别我没怎么看出来，但是跟Template模式相比，我觉得吧，他没有实现算法框架的封装，但是人家说了这也算是设计模式的一种，也就这样了，也许我根本没看懂？？看完这篇只记得一句话，favor composition over inheritance（组合优

提起Observer模式，或许有的人不是很清楚，但是MVC框架，相信IT行业的人很少不了解的，而MVC框架则是Observer模式的一个应用实例，从这可以看出，Observer的重要性和实用性，Observer模式要解决的问题是，建立一个一对多的依赖关系，并且当一变化时，依赖一存在的多也随之变化，现在看下Observer的示意图 #include"stdafx.h"#incl

Decorator模式主要是用于系统的更新等状况，可以这样认为，当我们为一个已经定义好的类，添加新的功能，通常情况下，我们继承该类来实现，通过继承还会加大继承的复杂度因为集成的深度会加深，所以我们要通过组合来实现现在先用Decorator模式图像代码是： #includeusing namesoace std;class Component{public:

面向对象的编程最终是为了提高模块内的内聚度，降低模块间的耦合度，bridge模式就是当我们在实现功能时，可能实现的方法种类很多，比如某一功能的实现是需要多种算法的，或者某一模块的功能实现有的是在windows平台下，有的是在linux下的，最终的功能相同，但是实现的具体是不同的。这时候就需要bridge模式，将功能需求和实现分离开来，直接向客户提供功能的是一个类，而其中保存了一个实现该功能

我一直在想FlyWeight模式和Composite模式有什么区别，因为，他们都有一个专门管理目标对象的类，都使用了容器，所不同的是Composite模式下，管理的类自身就是管理目标类的子类，同时还可以对所管理的类对象发号施令，而在FlyWeight模式下，管理的类自身与目标没有这种继承关系，他只是记录了目标类对象的一系列指针，并且除此之外没有任何其他队目标类的操作我们可以这样

builder模式一般是用在创建一个较为复杂的对象，通过且该对象会因为参数的不同最终而有所差别，而builder模式则主要是用于封装这个创建过程，其实现过程如下现在我们来解读一下这张图，我听喜欢这种使用图片的形式展示思想的，因为代码虽然具有语义的单一性，但是其可读性并不是很强，但是图片就不存在这种问题，Builder类是一个抽象基类，图中展示的四个函数是纯虚函数，等待子类的实现，其

本文主要是讲述创建型模式中一个比较特殊的模式-原型模式，这个模式呢，有个最大的特点是克隆一个现有的对象，这个克隆的结果有2种，一种是是浅复制，另一种是深复制，这里我们也会探讨下深复制和浅复制的原理，这样可能更方便大家理解这个原型模式的使用。我们都知道，创建型模式一般是用来创建一个新的对象，然后我们使用这个对象完成一些对象的操作，我们通过原型模式可以快速的创建一个对象而不需要提供专门的new

17.1.解释概念：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。main()，客户IWomen，发出请求者接口CWomen，请求者实现类CHandler，处理请求抽象类CFather，处理请求实现类，责任链之一CHusband，处理请求实现类，责任链之二CSon，处理

不知道该怎么写这篇博文，facade模式，嗯，应该可以这么说它是一种低程度的对象聚合，在具体实现的基础上进行一次整合，实现较高层次的功能实现，就如笔者看到的教材举得例子那样，毕业时需要三个章，一个是宿舍，一个是图书馆，另外一个是户籍科，将所有的这三个章盖完，则说明，你可以离校了，每盖一个章都需要不同的具体实现，但是离校时并不需要这些细节，他们只需要看到这三个章已经全部盖完即可，facade

Command模式通过将命令封装到一个对象当中，并且将接受请求对象（Receiver）的指针存放在ConcreteCommand对象当中，通过对象组合的方式进行解耦，当然命令的发送还需要一个执行者Invoker，即命令分发对象。#include"iostream"using namespace std;class Receiver{ public: Receiver(){

单例模式顾名思义就是要创建一个类的唯一变量不允许有第二个！因为这个太简单了，所以就写下代码来帮助记忆吧#includeusing namespace std;class singleton{ private: singleton();//构造函数是私有的不允许外部实例化,或者protected属性也行 public: static singleton*

现在说下adapter模式，adapter模式主要有两种，一种是类的adapter模式，这种adapter模式主要是使用类继承的方式来实现的，即主要有三个类，一个是实现功能的adaptee类，这个就好像是我们的第三方软件库中已经实现好的，第二个是target类，这个是我们软件为该功能保留的接口，第三个当然就是adapter类了。图示如下：这个设计模式一直不是太走心，或者说不太容易让

上次说到adapter模式有两种，一种是对象的adapter模式，一种是对象的adapter模式，我们知道adapter模式主要是为了使得不可兼容的接口可以在一起使用，关于类的adapter模式主要是使用了对象继承，使得adapter共有集成了Target，私有继承了adaptee，在Target的SpecificRequest函数中调用了adaptee的Request函数。而对象的adapt

Composite模式是一种结构性模式，顾名思义，他创建或者说管理的是一组对象，并且将这组对象，形成一种线性结构，而Composite模式则是将这组对象组成vector结构，Composite模式图如下：class Component{ protected: Component() {;} ~Component() {;} public:

所谓Proxy模式就是某行为应该是由某特定的类对象来执行，但是因为某种原因，交给另一个实体类来执行，该实体类则为类对象的代理，Proxy模式实现了逻辑和实现的彻底解耦，其实想想，这和Bridge模式，应该是类似但不相同的，Bridge模式实现了功能和实现的解耦，Bridge模式是在函数功能的粒子度上进行解耦的，但是Proxy则是在对象的粒度上进行解耦的，但是仔细想想，好像这俩是完全一样的，

一如既往的写下今天读到的Template模式，顾名思义，Template模式是一种模板，针对于算法框架相同，但是实现细节不同的环境之下，为了实现算法框架的相同，所以我们要使用一个共有的算法框架的基类，也就是Abstract类，他表明了我们使用的算法框架，而在实际的实现过程中，我们的实现细节是在其子类当中具体描述的，其图形化描述如下：具体实现是在ConcreteClass1和Conc

在笔者看来这是第一次比较有技术含量的设计模式，State模式，顾名思义，每个对象可能在不同的阶段拥有不同的状态，同时在不同的状态应该执行的是不同的行为，所以对于Context的构造指出就应该有State的存在表示当前所处的状态，同时对于每个不同的状态的行为也应该在State类对象中包含，因为行为的不同是因为状态的不同，下图就是State模式的示意图 #include"stda

Mediator模式主要是用于对象间的通信，我们知道任何对象都不能是单独存在的，通信对象之间的通信，需要有个执行体，如果是对象直接去进行通信势必会增加对象的负担，除此之外，还会增加对象之间的耦合度，要有一个专门的类进行通信，降低系统的复杂性，也是一种更为艺术的做法，下面是Mediator的示意图Mediator模式，其实不过就是在Mediator类当中记录下，要进行通信类的指针，然

Memento模式，究其根源来说是一种记录模式，记录用户之前所做的操作，然后可以为用户提供undo功能，即撤销，用术语来说呢，就是在不破坏要记录类的封装的前提下，捕捉类的一个内部状态，这样通过对该状态的保存提供恢复操作的功能，Memento模式示意图如下：Original类会有getState和setState存取状态函数，对于状态的保存，则有createMem和RestoreTo