继承(2)
继承(2)
实现一个不能被继承的类
这要怎么做到呢?
方法1(C++98):
把父类的构造函数私有化。
子类的构成必须调用父类的构造函数,但是父类的构造函数私有化后,子类看不见就不能调用了,由此子类就无法实例化出对象。
对于这种方法来说,如果不去定义子类对象,就不会报错。
方法2(C++11新增):
final关键字。final修改父类,子类就不能继承了。
这种方法就算不定义子类对象,也会报错。
继承与友元
友元关系不能被继承,也就是说父类友元的函数不能访问子类私有和保护成员,如下:
而解决的手段就是在子类中也对这个函数进行友元声明:
int main()
{Person p;Student s;// 编译报错:error C2248: “Student::_stuNum”: ⽆法访问 protected 成员 // 解决⽅案:Display也变成Student的友元即可 Display(p, s);return 0;
}
继承与静态成员
基类定义了static静态成员,则整个继承体系⾥⾯只有⼀个这样的成员。⽆论派⽣出多少个派⽣类,都 只有⼀个static成员实例。
class Person
{
public:string _name;static int _count;
};int Person::_count = 0;class Student : public Person
{
protected:int _stuNum;
};int main()
{Person p;Student s;// 这⾥的运⾏结果可以看到⾮静态成员_name的地址是不⼀样的 // 说明派⽣类继承下来了,⽗派⽣类对象各有⼀份 cout << &p._name << endl;cout << &s._name << endl;// 这⾥的运⾏结果可以看到静态成员_count的地址是⼀样的 // 说明派⽣类和基类共⽤同⼀份静态成员 cout << &p._count << endl;cout << &s._count << endl;// 公有的情况下,⽗派⽣类指定类域都可以访问静态成员 cout << Person::_count << endl;cout << Student::_count << endl;return 0;
}
我们可以把静态成员理解成全局的,它只是受类域限制而已。它并不存在对象里,而是存在静态区。它可以由我们的类域来指定访问,也可以用对象来访问:
cout << Person::_count << endl;
cout << Student::_count << endl;cout <<p._count << endl;
cout <<s._count << endl;
但一般我们是指定类域去访问,而不用对象访问。
多继承及其菱形继承问题
继承模型
单继承:⼀个派生类只有⼀个直接基类时称这个继承关系为单继承
多继承:⼀个派生类有两个或以上直接基类时称这个继承关系为多继承,多继承对象在内存中的模型是,先继承的基类在前面,后面继承的基类在后面,派生类成员在放到最后面。
菱形继承:菱形继承是多继承的⼀种特殊情况。菱形继承的问题,从下面的对象成员模型构造,可以看出菱形继承有数据冗余和二义性的问题,在Assistant的对象中Person成员会有两份。支持多继承就 ⼀定会有菱形继承,像Java就直接不支持多继承,规避掉了这里的问题,所以实践中我们也是不建议设计出菱形继承这样的模型的。
class Person
{
public:string _name; // 姓名
};class Student : public Person
{
protected:int _num; //学号
};class Teacher : public Person
{
protected:int _id; // 职⼯编号
};class Assistant : public Student, public Teacher
{
protected:string _majorCourse; // 主修课程
};int main()
{// 编译报错:error C2385: 对“_name”的访问不明确 Assistant a;a._name = "peter";// 需要显⽰指定访问哪个基类的成员可以解决⼆义性问题,但是数据冗余问题⽆法解决 a.Student::_name = "xxx";a.Teacher::_name = "yyy";return 0;
}
可以看到,这其实就是一个菱形继承的例子。
ios的信息在iostream中有两份。
那么,有没有解决方案呢?
虚继承
很多⼈说C++语法复杂,其实多继承就是⼀个体现。有了多继承,就存在菱形继承,有了菱形继承就有菱形虚拟继承,底层实现就很复杂,性能也会有⼀些损失,所以最好不要设计出菱形继承。多继承可以认为是C++的缺陷之⼀,后来的⼀些编程语言都没有多继承,如Java。
class Person
{
public:string _name; // 姓名 /*int _tel;int _age;string _gender;string _address;*/// ...};// 使⽤虚继承Person类
class Student : virtual public Person
{
protected:int _num; //学号
};// 使⽤虚继承Person类
class Teacher : virtual public Person
{
protected:int _id; // 职⼯编号
};// 教授助理
class Assistant : public Student, public Teacher
{
protected:string _majorCourse; // 主修课程
};int main()
{// 使⽤虚继承,可以解决数据冗余和⼆义性 Assistant a;a._name = "peter";return 0;
}
监视窗口展示的是处理后的,其实只有一份Person了。
数据冗余和二义性就都解决了。
IO库中的菱形虚拟继承
如果现在是这样一个不规则的菱形:
注意,我们把virtual加在B和C处。
因为在E中,是A会有两份,所以加在A的两个直接子类。
哪个类产生了冗余,其子类继承时就用虚继承。
最后,一般情况下不要设计出菱形继承,因为其使用和底层比我们想象的要复杂非常多。
对于菱形继承,既不放在Student,也不放在Teacher,而是单独放在一个地方。
所以,这个Assistant的构造要这么写:
我们无法只初始化Person,因为规定上:派生类的构造函数必须调用基类的构造函数初始化基类的那⼀部分成员。如果基类没有默认的构造函数,则必须在派生类构造函数的初始化列表阶段显式调用。
那么这个name给谁来初始化了呢?只传一个name,给Person初始化了,如果传三个name,Student和Teacher并不会去走这一步。
相当于,Person对于Assistant就像一个单独的父类。
再次总结,单继承随便用,多继承要看构不构成菱形继承,构成的话就要把设计改了。因为菱形继承会有数据冗余和二义性,然后就必须使用虚继承,而一使用虚继承,初始化等就会变得很复杂,底层效率也有一点损失。
多继承中指针偏移问题
下面说法正确的是()
A:p1p2p3 B:p1<p2<p3 C:p1==p3!=p2 D:p1!=p2!=p3
class Base1 { public: int _b1; };
class Base2 { public: int _b2; };
class Derive : public Base1, public Base2 { public: int _d; };
int main()
{Derive d;Base1* p1 = &d;Base2* p2 = &d;Derive* p3 = &d;return 0;
}
分析
这里是一个切片和多继承的问题。把子类给父类指针或引用,会把子类对象中父类的那部分切出来。
在内存中的分布是根据声明的顺序分布的。初始化列表初始化的顺序也是按照声明的顺序初始化的。继承之后,父类就在上面,如果是多继承,先继承的在前面。
如果现在我们给两个父类Base1 、Base2以及子类Derive的成员变量都加上缺省值,分别为1 、2 、3,然后我们来看看内存窗口里这三个成员变量的存储空间分布:
可以看到,内存中先存储的是Base1的成员变量,然后是Base2的成员变量,最后才是子类Derive的成员变量。
对象都是从低地址往高地址走的(栈是向下增长的)。
继承和组合
• public继承是⼀种is-a的关系。也就是说每个派生类对象都是⼀个基类对象。
• 组合是⼀种has-a的关系。假设B组合了A,每个B对象中都有⼀个A对象。
简单来说,继承和组合的区别就类似下面这张图:
• 继承允许你根据基类的实现来定义派生类的实现。这种通过生成派生类的复用通常被称为白箱复用 (white-boxreuse)。术语“白箱”是相对可视性而言:在继承方式中,基类的内部细节对派生类可见。继承⼀定程度破坏了基类的封装,基类的改变,对派生类有很⼤的影响。派生类和基类间的依赖关系很强,耦合度⾼。
• 对象组合是类继承之外的另⼀种复用选择。新的更复杂的功能可以通过组装或组合对象来获得。对象组合要求被组合的对象具有良好定义的接口。这种复⽤⻛格被称为黑箱复⽤(black-boxreuse), 因为对象的内部细节是不可⻅的。对象只以“⿊箱”的形式出现。组合类之间没有很强的依赖关系,耦合度低。优先使用对象组合有助于你保持每个类被封装。
那么,耦合度高好,还是耦合度低好呢?
耦合度低一点好,因为假如A写了100个接口,且对B都透明。A改动函数名、函数参数等,B就得随之改动。显然这样是不太好的。如果只开放部分接口给B,内部细节封装起来,是更好的。**低耦合,高内聚。**所以设计类,能开放的接口越少是越好的,一个不开放是不现实的。
• 优先使用组合,而不是继承。实际尽量多去用组合,组合的耦合度低,代码维护性好。不过也不太那么绝对,类之间的关系就适合继承(is-a)那就用继承,另外要实现多态,也必须要继承。类之间的关系既适合⽤继承(is-a)也适合组合(has-a),就用组合。
比如栈,就是一个两个都符合的,用组合更好。
本文到此结束。