GeekBand C++ Week9 Notes

C++设计模式

为了理解松耦合设计思想，掌握面向对象设计原则

什么是设计模式？

是一种解决方案的核心，可以避免重复劳动

设计模式不等于面向对象设计模式

底层思维：向下，如何把握机器底层从微观理解对象构造

语言构造，变易转换

内存模型

运行时机制

抽象思维：向上，如何将我们的现实世界抽象为程序代码，

面向对象

组件封装

设计模式

架构模式

深入理解面向对象：

向下：封装，继承，多态

向上：深刻把握面向对象机制所带来的抽象意义，理解如何利用这些机制来表达现实世界，掌握什么是好的面向对象设计

如何解决复杂性？

分解，人们面对复杂性有一个常见的做法：分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题

抽象：更高层次来讲，人们处理复杂性有一个通用的技术，由于不能掌握全部的复杂对象，我们选择忽视它的非本质性细节而去处理泛化和理想化了的模型

class Point{

public:

    intx;

    int y;

};

class Line{

public:

    Pointstart;

    Pointend;

    Line(constPoint& start, const Point& end, ){

        This->start= start;

        This->end= end;  

    }

};

抽象的过程

在shape里面有虚拟方法draw,一个形状负责画自己，实现自己的draw.

在子类中overide自己父类的虚函数

virtual void Draw(const Graphics& g){

g.DrawLine(Pens,Red, start.x, start.y, end.x, end.y);

}

class MainForm:public Form{

private:

pointp1;

point p2;

vector

shapeVector;//多态

public:

}

在后面对shapevector中的元素进行多态调用。

两种方法的区别，哪种更好？

客户需求的变化：

如果客户需要多加一个圆

//增加一个类

class Circle{

};

在mainform里增加一个

vector CircleVector

如果检测到要画圆则要判断将圆push——back到圆的vector里

然后刷新以后，要把圆显示出来

用抽象的方法，建立新的circle类

class Circle: public shape{

public:

//负责自己的draw

}

vector不需要动，因为是shape*指针

全都不用改变除了刷新

工厂模式里在刷新一个圆的时候也不需要改变

重用性得到了很高的提升

当需求变化的时候，更加方便

DRY！！！

由于不能掌握全部的复杂对象，处理泛化的问题

面向对象的设计原则

变化是复用的天敌，面向对象设计最大的优势在于抵御变化。

理解隔离变化

从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小。

各司其职

从微观层面来看，面向对象的方式更强调个各类的责任

在第一个例子里，画线的责任从mainform到了形状自己，接口一样但实际不一样。

对象是什么？

从语言实现层面来看，对象封装了代码和数据，

从规格层面来看，对象是一系列可以被使用的公共接口

从概念层面来看，

面向对象的设计原则//设计原则比模式更重要

依赖倒置原则（DIP）

高层模块（稳定）不应该依赖于低层模块（变化），二者都应该依赖于抽象（稳定）

抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）。

开放封闭原则（OCP）

对扩展开放，对更改封闭

类模块应该是可扩展的，但是不可以修改

单一职责原则（SRP）

一个类应该仅有一个引起它变化的原因

变化的方向隐含着类的责任

Liskov替换原则（LSP）

子类必须能够替换它们的基类（IS-A）

继承表达类型抽象

接口隔离原则（ISP）

不应该强迫客户程序依赖它们不用的方法

接口应该小而完备

优先使用对象组合，而不是类继承

类继承通常为白箱复用，对象组合通常为黑箱复用。

继承在某种程度上破坏了封装性，子类父类耦合度高

而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

封装变化点

使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良影响。

针对接口编程，而不是针对实现编程。

不将变量类型声明为具体的类，而是声明为某个接口，客户程序无需知道对象的具体类型，只需要知道对象所具有的接口。

减少系统中各部分的依赖关系，从而实现“高内聚，低耦合”类型的设计方案。

产业强盛的标志：接口标准化

模板方法

Template Method

GOF-23模式分类

设计模式的应用不应该先入为主，一上来就使用设计模式是对设计模式最大的误用，没有一步到位的设计模式。

重构的关键技法：

静态到动态，早绑定到晚绑定，继承到组合，编译时依赖到运行时依赖，紧耦合到松耦合

组件协作模式：

框架与应用程序的划分，组合协作模式通过晚期绑定，来实现框架和应用程序之间的松耦合，是二者之间协作时常用的模式。

典型模式：

template method

strategy

observer/event

动机：在软件构件过程中，某项任务常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因，比如框架和应用之间的关系，而无法和任务的整体机构同时实现

class library{

public:

    voidstep1(){ 

    //…

    }

    voidstep3(){

    //…

    }

    void step5(){

    }

};//程序库开发人员

class Application{

    voidstep2{

    }

    void step4{

    }

};

int main(){

    Librarylib();

    Applicationapp();

    Lib.step1();   

    If(app.step2()){

        Lib.step3();

    }

….

}

另外一种做法：

库的开发人员

除了1，3，5，也写step2和step4

virtualbool step2(){}

virtualvoid step4(){}

把run()写在类里，1，3，5是protected,虚的析构函数。

子类重写实现

library* pLIb = new Apllication();

plib->run();

delete plib;

前一种方法lib开发人员开发1，3，5三个步骤，app开发人员开发2，4两个步骤，和程序主流程

另一种lib开发人员写1，3，5三个步骤和程序主流程，app开发人员开发2，4两个步骤。

第一种是app调用lib的，第二种是lib的调用app的

第一种写法是一种早绑定的写法，因为lib一般写的早，程序库写的早。晚的东西调用早的东西，但在面向对象语言中，有晚绑定的机制，lib写的早但是它调用app，所以是晚绑定。模式定义一个操作算法的骨架（稳定），而将一些步骤延迟到子类中，template method是的子类可以不改变一个算法结构即可以重定义override，重写该算法的某些特定步骤。

为什么叫template method?run就是一个样板

稳定中有变化，2，4支持变化，是虚函数的多态调用

c++中稳定的要写成非虚函数，变化的要写成虚函数

设计模式的假定条件是必须有一个稳定点

也一定有变化，设计模式的最大的作用就是在稳定和变化之间寻找一个平衡点，把兔子关进笼子里。

在具体实现方面，被template method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法，虚方法），但一般推荐把它们设置为protected方法。

“不要调用我，让我来调用你”的反向控制结构。

策略模式：

strategy策略模式是一个组件协作类的模式，实现框架和应用程序之间的松耦合

动机：在软件构件过程中，有些对象使用的算法可能多种多样经常改变，如果将这些算法都编码到对象中，将会使对象变得复杂，有时候支持不适用的算法也是一个性能负担，透明得更改，使算法和对象解耦。

Enum taxbase{

CN_Tax,

Us_tAX

dE_TAX

};

class SalesOrder{

    texbasetax;

public:

    doublecalculateTax(){

    if(tax== cn_tax){

    }

    else if(tax ==us_tax){

    }

    else if(tax==de_tax){

    }

}

};

有没有可能未来支持其他国家的税法

class taxStrategy{

public:

virtualdouble calculate(const context& context) = 0;

virtual~taxstrategy(){}

};

class CNTax:public taxstrategy{

public:

virtualdouble calculate(const context& context){}

};

class ustax: public taxstrategy{

public:

virtualdouble calculate(const context& context){}

};

…

class salesorder{

private:

taxstrategy*strategy;

public:

salesorder(strategyfactory*strategyfactory){

this->strategy= strategyfactory->newstrategy();

}

~salesorder(){}

public doublecalculatetax(){

contextcontext();

double val =

strategy->calculate(context);//多态调用

}

};

把一些列算法一个个封装起来并且使他们可以互相替换，是算法独立于客户程序（稳定）而变化（扩展，子类化）

strategy使类型在运行时方便地根据需要在各个算法之间切换

strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句实在解耦合。

如果Strategy对象没有实例变量，各个上下文可以共享一个strategy变量，从而节省对象开销。

有很多ifelse代码不会被真正使用但是要存在缓存里，使得有用的代码被挤到主存里，但这个不是主要的好处。

Observer/event观察者模式

动机：需要为某些对象建立一种通知依赖关系-一个对象的状态发生改变，所有依赖对象（观察者对象）都得到通知，如果这样的依赖关系很紧密，不能很好地抵御变化。

Class mainform:public forms{

    Textbox*txtfilepath;

    Texbox*txtfilenumber;

Public:

    Voidbutton_click(){

    Stringfilepath = txtfilepath->gettext();

    Intnumber = atoi(txtfilenumber->gettext().c_str());

    Filesplittersplitter(filepath, number);

    Splitter.split();

}

};

class filesplitter{

stringm_filepath;

intm_filenumber;

public:

filesplitter(conststring& filepath, int filenumber):

{}

void split(){

//读取大文件

//分批次向小文件中写入

for(int I = 0; i

//…

}

}

};

需求是提供一个进度条，来展示完成进度

首先在maiform上有一个progressbar* progressbar成员

在file_splitter里也放一个progressbar

依赖：A依赖B，A在编译的时候只有B存在才能通过。

编译是依赖，

当我不需要用这个bar的时候会出问题，这个progressbar其实是一个通知。通知可以用抽象的方式来表达，而不是用一个控件

class IProgress{

public:

virtualvoid DoProgress(float value) = 0;

virtual~IProgress()

};

所以在filesplitter里就变成了

IProgress* m_Iprogress//抽象通知机制

If(m_Iprogress != nullptr){

M_Iprogress->DoProgress(i+1)/m_filenumber;

}

然后mainform多重继承Iprogress，C++一般用到多重继承都是一个基类和接口

装饰模式：

Decorator装饰模式

“单一职责模式”在软件组件设计中，如果责任划分不清晰，使用继承得到的结果往往会让子类急剧膨胀，同时充斥着重复代码，这时候关键要划清责任。

典型的模式有decorator和bridge。

Class stream{

Public:

    Virtualchar Read(int number) = 0;

    Virtualvoid seek(int position) = 0;

    Virtualvoid write(char data) = 0;

    Virtual~Stream(){}

};

class filestream : public stream{

};

class Networkstream: public stream{

};

我们需要对流的主体进行曹组偶以后才能加密。

Class CtyptoFileStream : public FileStream{

Public:

    Virtualchar Read(int number){

    FileStream:read(number);//读文件流

}

};

缓冲操作

//额外的加密操作

//额外的缓冲操作

这个设计的问题

最顶上是stream，被filestream, networkstream和memeorystream三种继承，然后每个分别有加密和缓冲的流

这样流就有很多，但其中有重复的代码

如何重构？

取消继承，把父类当做一个对象放入类中

然后再把各个父类做成多态，用基类来表示，会发现所有的类全都一样，只是运行的时候new出来的对象不一样。

但是要保证流的方法是虚方法，所以要继承自基类stream

桥模式：

由于某些类型的固有实现逻辑，使得他们有多个变化的维度

class messager(

public:

virtualvoid login

virtualvoid sendmessage

virtualvoid sendpicture

virtualvoid playsound

virtualvoid drawshape

virtualvoid writetext

virtual~message

);

我们还要支持PC平台和mobile平台的设计

class PCMessagerBase: public Messager{

public:

//重写后面的几个方法

};

class MobileMessagerBase: public Messager{

};

我们会发现在不同的平台上要支持不同的功能

class PCMessageLite: public PCmessagerBase{

};

class PCMessagerPerfect: publicPCMessagerBase{

};

class MobileMessagerLite: publicMobileMessagerBase{

};

后面的类可以用messager的多态来实现，然后发现后面的lite和perfect并没有重载前面的后面几个方法，所以要把messager拆分开成两个类。。

和decorator方法很像

如果子类里有重复的字段，都要往上提

abstraction和implementor，在abstraction里有一个implementor的指针，并且两个东西分别有各自的子类，向两个不同的方向延伸。