(GeekBand)C++面向对象高级编程(上)第三周笔记
组合与继承
Composition(复合)
复合关系一个类包含另一个类(has-a),可以通过Adapter改造一个类,即一个对象为另一个对象的子对象(成员)。
在构造时由内而外,先调用内部类的构造函数,在构造自己;在析构时,先析构自己再析构内部类。
Delegation(委托)
委托关系一个类里面有一个指针指向另一个类,当前类委托另一个类实现各种操作。可以多个对象里面的指针指向同一个委托对象。两个类的生命周期不一致。
Handle/Body模式:将类的接口和类的实现相互分开,对实现类的修改不会影响对外的使用。其相比继承而言有更大的灵活度。
Inheritance(继承)
继承class class_name2: access_specifiers class_name1
{
}
class1完全包含class2的内容,calss1为基类,class2为派生类。其构造与析构顺序和复合关系一样,不同的是对于编译器来说class2对象本身就是一个class1对象。class1的引用和指针完全可以绑定到class2对象上。即
class2 cl2;
class1 &cl1=cl2;
class1 *p=&cl2;
完全是合法的。但是cl1还是一个class1的引用,p还是一个class1的指针,所以需要一个class2类型的指针和引用的地方,不能用p和cl1来代替。
虚函数与多态
基类的析构函数必须为virtual(虚函数)。
non-virtual函数:不能被子类重新定义(override);
virtual函数:基类已经默认定义了,但是希望子类重新定义;
pure virtual函数:没有默认定义,子类必须重新定义;对于含有纯虚函数的类成为抽象类,不能产生实例,只能被派生类继承,且如果派生类没有重新定义的话,派生类也为一个抽象类。
继承+复合关系下的构造与析构
基类包含另一个类然后被继承构造时先构造Component,然后构造基类Base,最后才构造Derived。析构时先调用Derived的析构函数,然后析构Base最后进行Component的析构。
派生类自己包含另一个类经测验Base的构造函数会先于Component的构造函数调用;析构时Component的析构函数先于Base的析构函数调用。
委托+继承(composite)
文件系统
为了让composite中的容器能够放入primitive和composite两种不同的类,那么可以让这两个类有同一个基类(继承)。然后基类的指针(委托)可以指向任何一个派生类。
基类不知道会派生出哪些派生类,而有需要知道派生出的类的名称。在写出派生类之后,派生类创建一个自己这种静态对象(LSAT),然后把自己的静态对象添加到基类的addPrototype里面的指针中。然后需要创建某一个派生类对象时通过相应的静态对象中的clone函数复制一个当前对象,然后为复制出的对象的变量赋值完成一个对象的创建。
参考资料sourcemaking.com/design_patterns/prototype;该网站列出了一些参考示例,使用prototype的目的,与存在的问题。
作业过程中面临的问题与解决方案
在本次作业中有两套不同的解决方案,一种是按照普通的继承与复合关系完成的;另一种是通过prototype设计模式进行作业(未完成)。
在普通的继承关系中存在以下问题:
1. 作业中要求通过一个传统数组保存两种类型的对象,但是对于数组的描述中明确表示了数组是相同类型的数据按照一定的数序排列。
解决方案是,由于两中类都是同一个类Shape的派生类,而Shape形指针又完全可以指向Shpae及其派生类的对象,所以可以创建一个Shape形指针数组,以达到题目要求。
2. 由于数组中是保存的Shape形指针,当指针解引用时也被编译器当作了一个Shape形的对象。在输出流操作符<<重载时,为了使std::cout满足操作习惯不能采用成员函数形式重载。而在普通函数重载时就要为Circle与Rectangle各自进行一个重载,参数如下:
std::ostream& operator <<(std::ostream &os, Rectangle const &re);
std::ostream& operator <<(std::ostream &os, Circle const &ce);
可以看到区别它们之间不同的为形参列表,但是我的对象是由Shape指针保存的,不能有效区分,导致不能调用相应的流操作符。
解决方案为:可以采用以下两种方案,将expression转换为type_id对象的指针或引用
dynamic_cast<type-id>(expression)
static_cast < type-id > ( expression )
在进行由派生类道基类的转化时,它们俩没什么区别。但是当由基类向派生类转化时,dynamic_cast具有类型检查,比如expression确实指向一个派生类对象时,没问题返回一个派生类的指针,当expression没有指向type-id类时返回一个空指针,可用于判断。而static_cast由于没有类型检查所以下行转换时时不安全的。
3. 对于**ptr指针作为函数形参时const的使用如下:
const MyStructure * *ppMyStruct;
// ptr --> ptr --> const MyStructure
MyStructure *const *ppMyStruct;
// ptr --> const ptr --> MyStructure
MyStructure * *const ppMyStruct;
// const ptr --> ptr --> MyStructure
如上,如果ptr所指的指针与指针所指的值还有ptr本身都不会在函数中改变的话,可以采用 const *const *const ptr;这种方式。没有找到对这种用法的相关建议是否应该少用之类的,但是这种用法确实对于理解有一定的困难。
在使用prototype设计模式进行作业
1. 这种设计模式强调我们在运行时去创建一个对象时,不需要完全的重新初始化对象,并且不需要知道对象属于哪一个派生类也能够创建出相应的对象。但是如果两个派生类所需的构造函数形参列表不同,就不能通过*shape=class_name()来改变一个对象里面的值,和上面一样也要通过类型的强制转换“dynamic_cast(expression)”。而像示例代码这样添加一个draw()纯虚函数,用以改变对象的值,但是纯虚函数在复写的时候又要求形参列表要和基类一样,而circle和rectangle所需的参数数量肯定是不一样的,最后只有采用笨办法dynamic_cast改变值。但是网上说用了dynamic_cast就代表类设计上就有问题,一个完好的类的设计是不需要用到dynamic_cast的~~~~
2. 这种设计模式在规模较小的程序中,代码复杂度提升太大,为了实现这个模式而添加的代码都差不多和普通的一个派生类的所有代码行数相当。反而不如普通的直接继承更方便,也许是我反应慢,照着(sourcemaking.com)里面的示例代码编写了一个以这种模式为基础的作业,感觉有时候自己都看不懂了~~~~
总结:本章最难的我认为就数设计模式这部分了,特别是prototype这种,看示例代码好像很简单,但是一到自己写这种设计模式的代码的时候,就完全不知道该写什么了呢。反而不明不白的写了好多完全没有用的代码。