CC++与设计模式基础课程讲义v104教学提纲Word格式文档下载.docx
《CC++与设计模式基础课程讲义v104教学提纲Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《CC++与设计模式基础课程讲义v104教学提纲Word格式文档下载.docx（170页珍藏版）》请在冰点文库上搜索。
通常和对象的创建有关，涉及到对象实例化的方式。
（共5种模式）
结构型模式：
描述的是如何组合类和对象以获得更大的结构。
（共7种模式）
行为型模式：
用来对类或对象怎样交互和怎样分配职责进行描述。
（共11种模式）
创建型模式用来处理对象的创建过程，主要包含以下5种设计模式：
1，工厂方法模式（Factory
Method
Pattern）的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。
2，抽象工厂模式（Abstract
Factory
Pattern）的意图是提供一个创建一系列相关或者相互依赖的接口，而无需指定它们具体的类。
3，建造者模式（Builder
Pattern）的意图是将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
4，原型模式（Prototype
Pattern）是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
5，单例模式（Singleton
Pattern）是保证一个类仅有一个实例，并提供一个访问它的全局访问点。
结构型模式用来处理类或者对象的组合，主要包含以下7种设计模式：
6，代理模式（Proxy
Pattern）就是为其他对象提供一种代理以控制对这个对象的访问。
7，装饰者模式（Decorator
Pattern）动态的给一个对象添加一些额外的职责。
就增加功能来说，此模式比生成子类更为灵活。
8，适配器模式（Adapter
Pattern）是将一个类的接口转换成客户希望的另外一个接口。
使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
9，桥接模式（Bridge
Pattern）是将抽象部分与实际部分分离，使它们都可以独立的变化。
10，组合模式（Composite
Pattern）是将对象组合成树形结构以表示“部分--整体”的层次结构。
使得用户对单个对象和组合对象的使用具有一致性。
11，外观模式（Facade
Pattern）是为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
12，享元模式（Flyweight
Pattern）是以共享的方式高效的支持大量的细粒度的对象。
行为型模式用来对类或对象怎样交互和怎样分配职责进行描述，主要包含以下11种设计模式：
13，模板方法模式（Template
Pattern）使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
14，命令模式（Command
Pattern）是将一个请求封装为一个对象，从而使你可用不同的请求对客户端进行参数化；
对请求排队或记录请求日志，以及支持可撤销的操作。
15，责任链模式（Chain
of
Responsibility
Pattern），在该模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。
请求在这个链上传递，直到链上的某一个对象决定处理此请求，这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。
16，策略模式（Strategy
Pattern）就是准备一组算法，并将每一个算法封装起来，使得它们可以互换。
17，中介者模式（Mediator
Pattern）就是定义一个中介对象来封装系列对象之间的交互。
终结者使各个对象不需要显示的相互调用
，从而使其耦合性松散，而且可以独立的改变他们之间的交互。
18，观察者模式（Observer
Pattern）定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
19，备忘录模式（Memento
Pattern）是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
20，访问者模式（Visitor
Pattern）就是表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
21，状态模式（State
Pattern）就是对象的行为，依赖于它所处的状态。
22，解释器模式（Interpreter
Pattern）就是描述了如何为简单的语言定义一个语法，如何在该语言中表示一个句子，以及如何解释这些句子。
23，迭代器模式（Iterator
Pattern）是提供了一种方法顺序来访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示。
1.2设计模式基本原则
最终目的：
高内聚，低耦合
1）开放封闭原则（OCP,OpenForExtension,ClosedForModificationPrinciple）
类的改动是通过增加代码进行的，而不是修改源代码。
2）单一职责原则（SRP,SingleResponsibilityPrinciple）
类的职责要单一，对外只提供一种功能，而引起类变化的原因都应该只有一个。
3）依赖倒置原则（DIP,DependenceInversionPrinciple）
依赖于抽象（接口）,不要依赖具体的实现（类），也就是针对接口编程。
4）接口隔离原则（ISP,InterfaceSegegationPrinciple）
不应该强迫客户的程序依赖他们不需要的接口方法。
一个接口应该只提供一种对外功能，不应该把所有操作都封装到一个接口中去。
5）里氏替换原则（LSP,LiskovSubstitutionPrinciple）
任何抽象类出现的地方都可以用他的实现类进行替换。
实际就是虚拟机制，语言级别实现面向对象功能。
6）优先使用组合而不是继承原则（CARP,Composite/AggregateReusePrinciple）
如果使用继承，会导致父类的任何变换都可能影响到子类的行为。
如果使用对象组合，就降低了这种依赖关系。
7）迪米特法则（LOD,LawofDemeter）
一个对象应当对其他对象尽可能少的了解，从而降低各个对象之间的耦合，提高系统的可维护性。
例如在一个程序中，各个模块之间相互调用时，通常会提供一个统一的接口来实现。
这样其他模块不需要了解另外一个模块的内部实现细节，这样当一个模块内部的实现发生改变时，不会影响其他模块的使用。
（黑盒原理）
案例图
开闭原则案例
依赖倒转
1）
2）
迪米特法则
1）和陌生人说话
2）不和陌生人说话
3）与依赖倒转原则结合某人和抽象陌生人说话让某人和陌生人进行解耦合
2创建型模式
2.1单例模式
2.2.1概念
单例模式是一种对象创建型模式，使用单例模式，可以保证为一个类只生成唯一的实例对象。
也就是说，在整个程序空间中，该类只存在一个实例对象。
GoF对单例模式的定义是：
保证一个类、只有一个实例存在，同时提供能对该实例加以访问的全局访问方法。
2.2.2为什么使用单例模式
在应用系统开发中，我们常常有以下需求：
-在多个线程之间，比如初始化一次socket资源；
比如servlet环境，共享同一个资源或者操作同一个对象
-在整个程序空间使用全局变量，共享资源
-大规模系统中，为了性能的考虑，需要节省对象的创建时间等等。
因为Singleton模式可以保证为一个类只生成唯一的实例对象，所以这些情况，Singleton模式就派上用场了。
2.2.3实现单例步骤常用步骤
a）构造函数私有化
b）提供一个全局的静态方法（全局访问点）
c）在类中定义一个静态指针，指向本类的变量的静态变量指针
2.2.4饿汉式单例和懒汉式单例
懒汉式
#include<
iostream>
usingnamespacestd;
//懒汉式
classSingelton
{
private:
Singelton（）
{
m_singer=NULL;
m_count=0;
cout<
<
"
构造函数Singelton...do"
<
endl;
}
public:
staticSingelton*getInstance（）
if（m_singer==NULL）//懒汉式：
1每次获取实例都要判断2多线程会有问题
{
m_singer=newSingelton;
}
returnm_singer;
staticvoidprintT（）
m_count:
m_count<
staticSingelton*m_singer;
staticintm_count;
};
Singelton*Singelton:
:
m_singer=NULL;
//懒汉式并没有创建单例对象
intSingelton:
m_count=0;
voidmain01_1（）
cout<
演示懒汉式"
Singelton*p1=Singelton:
getInstance（）;
//只有在使用的时候，才去创建对象。
Singelton*p2=Singelton:
if（p1!
=p2）
不是同一个对象"
else
是同一个对象"
p1->
printT（）;
p2->
system（"
pause"
）;
return;
}
//////////////////////////////////////////////////////////////////////////
//俄汉式
classSingelton2
Singelton2（）
staticSingelton2*getInstance（）
//if（m_singer==NULL）
//{
//m_singer=newSingelton2;
//}
staticvoidSingelton2:
FreeInstance（）
if（m_singer!
=NULL）
deletem_singer;
m_singer=NULL;
m_count=0;
staticSingelton2*m_singer;
Singelton2*Singelton2:
m_singer=newSingelton2;
//不管你创建不创建实例，均把实例new出来
intSingelton2:
voidmain（）
演示饿汉式"
Singelton2*p1=Singelton2:
Singelton2*p2=Singelton2:
Singelton2:
FreeInstance（）;
2.2.5多线程下的懒汉式单例和饿汉式单例
//1"
懒汉"
模式虽然有优点，但是每次调用GetInstance（）静态方法时，必须判断
//NULL==m_instance，使程序相对开销增大。
//2多线程中会导致多个实例的产生，从而导致运行代码不正确以及内存的泄露。
//3提供释放资源的函数
讨论:
这是因为C++中构造函数并不是线程安全的。
C++中的构造函数简单来说分两步：
第一步：
内存分配
第二步：
初始化成员变量
由于多线程的关系，可能当我们在分配内存好了以后，还没来得急初始化成员变量，就进行线程切换，另外一个线程拿到所有权后，由于内存已经分配了，但是变量初始化还没进行，因此打印成员变量的相关值会发生不一致现象。
多线程下的懒汉式问题抛出：
#include"
stdafx.h"
windows.h"
winbase.h"
process.h>
iostream"
count++;
cout<
"
Singelton构造函数begin\n"
endl;
Sleep（1000）;
Singelton构造函数end\n"
//防止拷贝构造和赋值操作
Singelton（constSingelton&
obj）{;
Singelton&
operator=（constSingelton&
staticSingelton*getSingelton（）
//1"
//2多线程中会导致多个实例的产生，从而导致运行代码不正确以及内存的泄露。
//3提供释放资源的函数
returnsingle;
staticSingelton*releaseSingelton（）
if（single!
=NULL）//需要判断
cout<
释放资源\n"
deletesingle;
single=NULL;
voidpirntS（）//测试函数
printf（"
SingeltonprintStestcount:
%d\n"
count）;
staticSingelton*single;
staticintcount;
//note静态变量类外初始化
single=newSingelton（）;
count=0;
int_tmainTTT（intargc,_TCHAR*argv[]）
Singelton*s1=Singelton:
getSingelton（）;
Singelton*s2=Singelton:
if（s1==s2）
ok....equal"
not.equal"
s1->
pirntS（）;
Singelton:
releaseSingelton（）;
hello...."
return0;
unsignedintthreadfunc2（void*myIpAdd）
intid=GetCurrentThreadId（）;
printf（"
\nthreadfunc%d\n"
id）;
return1;
voidthreadfunc（void*myIpAdd）
getSingelton（）->
int_tmain（intargc,_TCHAR*argv[]）
inti=0;
DWORDdwThreadId[201],dwThrdParam=1;
HANDLEhThread[201];
intthreadnum=3;
for（i=0;
i<
threadnum;
i++）
//hThread[i]=（HANDLE）_beginthreadex（NULL,0,&
threadfunc,NULL,0,&
dwThreadId[i]）;
hThread[i]=（HANDLE）_beginthread（&
threadfunc,0,0）;
if（hThread[i]==NULL）
printf（"
beginthread%derror!
!
\n"
i）;
break;
}
//等待所有的子线程都运行完毕后,才执行这个代码
WaitForSingleObject（hThread[i],INFINITE）;
等待线程结束\n"
//CloseHandle（hThread[i]）;
2.2.6多线程下懒汉式单例的Double-CheckedLocking优化
新建MFC对话框应用程序。
方便使用临界区类对象，同步线程
//MFCDiagram应用程序
01单例优化.h"
01单例优化Dlg.h"
afxdialogex.h"
//临界区
staticCCriticalSectioncs;
//manpthread_create（）
classSingleton
Singleton（）
TRACE（"
Singletonbegin\n"
Singletonend\n"
Singleton（constSingleton&
Singleton&
operator=（constSingleton&
staticvoidprintV（）
printV..\n"
//请思考；
懒汉式的Double-Check是一个经典问题！
为什么需要2次检查“if（pInstance==NULL）”
场景：
假设有线程1、线程2、线程3，同时资源竞争。
//1）第1个、2个、3个线程执行第一个检查，都有可能进入黄色区域（临界区）
//2）若第1个线程进入到临界区，第2个、第3个线程需要等待
//3）第1个线程执行完毕，cs.unlock（）后，第2个、第3个线程要竞争执行临界区代码。
//4）假若第2个线程进入临界区，此时第2个线程需要再次判断if（pInstance==NULL）”，若第一个线程已经创建实例；
第2个线程就不需要再次创建了。
保证了单例；
//5）同样道理，若第2个线程，cs.unlock（）后，第3个线程会竞争执行临界区代码；
此时第3个线程需要再次判断if（pInstance==NULL）。
通过检查发现实例已经new出来，就不需要再次创建；
保证了单例。
staticSingleton*Instantialize（）
if（pInstance==NULL）//doublecheck
{
cs.Lock（）;
//只有当pInstance等于null时，才开始使用加锁机制二次检查
if（pInstance==NULL）
{
pInstance=newSingleton（）;
}
cs.Unlock（）;
returnpInstance;
staticSingleton*pInstance;
Singleton*Singleton:
pInstance=0;
voidCMy01单例
升级会员 