您现在的位置是:首页 > 文章详情

C++面向对象高级编程(上) 第三周 侯捷 类与类之间的关系

日期:2018-11-23点击:421

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图)

原文链接:https://yq.aliyun.com/articles/681123
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章