Composition（复合）——has a

类中有类  Adapter（一种设计模式名）

例如：queue里面包含了deque，他通过调用deque的函数来实现增加的功能。

所有的功能都在的deque中完成了，queue想拥有deque的功能，就这么做。

queue里面，只实现了调用个deque的功能，并没有实现deque的全部功能。

并不是所有的复合都长成这样，我们这里是用adapter（一种设计模式）来讲而已。

 

 

Composition从内存的角度看

看中间那个矩形（deque），他里面有两个Itr对象，一根指针和一个unsigned int类型的整数，因此他的大小是16*2+4+4=40字节（因为Itr对象（右一矩形）中有四根指针，所以大小为16字节）。

再看左侧的queue类，由于他里面只包含一个deque类的对象，因此queue的大小也是40.

 

 

 

Composition（复合）关系下的构造和析构函数

 

构造的过程中——由内而外的构造

container的构造函数先调用component的默认的构造函数，如果你希望调用别的构造函数，你需要自己写调用的构造函数以及函数里面的参数，这样编译器才能知道你要调用哪一个构造函数。

 

析构的过程——由内而外的析构

container的析构函数首先执行字节的析构函数，然后调用component的析构函数。

 

 

 

 

 

 

 

Delegation委托    Composition by reference

handle/body模式（又叫桥接模式）

用指针相连的话，他们的生命不一致。在composition关系中，两个类同生共死。

在delegation中，我需要调用你的时候，才会创建你。

上图中的两个类，左边就是Handle，右边就是Body。外界只能看见Handle。

 

编译防火墙

Handle中的指针可以指向不同的实现类，这就有了一种弹性。右边的类，无论怎么动都不影响左边，也就是不影响客户端。这个手法又叫做编译防火墙

如果要跟人家共享，切记，千万不能牵一发而动全局。也就是说，这里abc要共享这个hello，如果a把hello修改了，不能影响b和c对于hello的应用。

 

copy on write

解决办法就是，当a想对hello修改的时候，系统就单独拿出一份来让a修改。这个概念就是copy on write。写的时候，给你一份副本去让你写。

 

 

 

Inheritance 继承  is -a

父类的数据是被完整继承下来的。父类数据是被完整的继承下来的。

（上图中的子类不仅仅有自己的_M_data，还有父类的那两个指针_M_next和_M_prev）。

父类函数的调用权也被继承下来。

继承最有价值的地方是他跟虚函数搭配起来的时候。

使用public继承，就是要表达is a的概念，is a 即“是一种”这种概念。

 

 

 

Inheritance(继承)关系下的构造和析构

构造由内而外

构造时，先调用父类的默认构造函数，再调用子类的析构函数

 

析构是由外而内（父类的析构函数必须是virtual，不然不会由外而内的析构）

析构时，先析构子类，再析构父类。为什么父类的析构函数需要是虚函数，请看下文。

 

 

 

 

虚函数与多态

Inheritance(继承) with virtual function(虚函数)

概念

子类拥有调用父类成员函数的调用权。

 

 

例子——template method（method是函数的意思）应用程序的框架

在main里面，创建一个子类对象，通过子类对象调用父类函数

 

 

 

 

至于上图中，为什么运行到Serialize()的时候就跑去CMyDoc中去调用virtual Serialize（）  ：

由于调用OnFileOpen()的是myDoc，所以调用实际可以写成：

。谁调用的，this就指向谁，所以myDoc的地址就传入调用的函数OnFileOpen()中去了（图中没有写出来，是因为传的是this隐藏指针，成员函数都有一个this隐藏指针，该指针由编译器替我们写，我们不用写）。

在调用Serialize()的时候，编译器眼中是如图所示：

Serialize()是通过this来调用，而this是谁，this是myDoc。MyDoc就是如图所示：

因此，Serialize()是通过this来调用，而this是上图所示，所以函数运行到Serialize()的时候就跑去CMyDoc中去调用virtual Serialize（）。

 

 

 

请自己去检验一下，如下图所示的两种关系中，内存的分布情况如何（可以通过观察系统调用构造函数的顺序来判断）

 

 

 

 

 

 

Delegation（委托）+Inheritance（继承）的在相关设计

 

希望对于同一个数据，用多种不同的窗口，通过不同的方式进行观察，解决办法如下：

 

 

observer（观察者模式）

相应的实现原理如下：

（左边是delegation的关系。左边这个类里面attach函数可以添加窗口，notify函数用来通知美国observer来更新数据）

 

 

 

 

Composite（这也是一种设计模式）

 

为什么容器里面放指针

在容器里面放的东西要一样的大小，所以容器里面放的不是对象，而是指针（即Componet*），因为指针是一样的大小

 

在Component中，没有把add函数设计成纯虚函数，因为

如果你设计成纯虚函数，那么子类就一定要去定义它。而左侧的子类primitive，没有办法去做加的动作，因此没有把add写成纯虚函数。

 

 

 

 

prototype（原型模式）——我希望创建一个未来的对象的解决方案

当希望创建未来的子类对象的时候，此事并不知道子类的类名，解决办法就是：

让子类都创建一个自己，当成prototype（原型）。当父类看到这些原型的时候，就以此为蓝本去复制他，这就相当于父类在创建了。

写代码的时候，先写type name，再写object name，可是画图的时候刚好相反，如图：

 

子类创建原型的例子如下：

上图中，创建一个静态的对象（有下划线就代表静态）

 

 

创建出来的原型，如何被父类看得到呢？

静态的原型在创建自己的时候会调用构造函数，这里的构造函数是private（如下图）。我们借用构造函数去调用函数，而addprototype是由父类（）写的。而这个addprototype函数会把得到的指针挂到父类的容器里（）。此时，父类就能看到子类创建的这个原型了。

 

 

然后，每个字了I都要有个函数clone（）（如图），从下图（下图是一个子类的UML图）中可以看出，clone的作用就是new一个自己。因为刚刚已经有一个原型了，我们可以通过原型来调用clone这个函数来创建对象。如果没有原型，就没办法调用clone这个函数

 

 

如果你问：我不要原型，我让clone是一个静态函数，那不也是调用的到吗

但是静态函数的调用一定要有class name，可是父类并不知道以后创建的子类的class name，所以只能用原型模式。

 

 

原型模式的例子的整体UML架构如下

 

这样的设计模式对于子类来说，合理吗？

子类本可以无忧无虑，这里又要有静态的创建自己，又要构造原型，又要添加clone函数，是不是增加负担了？

合理的，不可能你什么都不做就和框架搭配到一起去

 

 

原型模式的父类源代码

父类父类中设置了纯虚函数clone

 

 

上图中——Class本体的static类型的data。一定要在class外面定义，如下图所示：

 

原型模式的子类的源代码

分析上图

第11行——clone（）函数，new了一个自己。而那个静态的自己在哪里呢？在第22行

静态的自己创建出来之后，会调用第24行的构造函数。使用第25行的addPrototype函数来把自己放上去了。

 

 

观察下方的子类的UML图，发现咱俩有两个构造函数，一个的private的，一个是protected的。为什么要有两个构造函数呢？

因为迪奥哟经函数clone（）的时候会调用构造函数，如果调用经那个私有的构造函数，而该构造函数会调用addPrototype（）来把自己加到父类的原型数组里面去，而那里面已经有一个自己了，因此，不能让clone()调用到那个private的构造函数。

 

 

第二个构造函数不能放在public里面，因为不打算被外界调用。那么放在private里面还是放在protected里面呢？

其实都可以，只要能跟那个调用addPrototype（）函数的构造函数区分开就行。

子类的UML图如下（为了便于观察，所以这里又贴一次子类的UML图）