明智而审慎地使用private继承

本文探讨了C++中私有继承的概念及其应用场景,对比了私有继承与复合设计的不同之处。通过实例说明了如何使用复合设计来替代私有继承,减少类间的耦合度。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

之前说过public继承是is-a关系。如下例子

class person
{
}

class student:public person
{
}

显然学生就是人。那private继承显然不是is-a关系,那他意味这什么呢?
如果classes之间的继承关系是private,编译器不会自动将一个derived class对象,转换为一个base class对象、再有,由private base class继承而来的所有成员,在derived class中都会变成private属性,纵使他们在base中原本是protected或public属性。
private 继承意味着根据某物实现。如果class D以private继承class B,其实你的用意是为了采用class B内已经备妥的某些特性,不是因为B对象和D对象存在由任何观念上的关系,所以private继承纯粹只是一种实现技术。private继承在软件设计层面上没有意义,其意义之存于软件实现层面。但这里有一句忠告:尽可能使用复合(composition),必要时才使用private继承。

现在有个widget calss,需要定时执行一些任务。刚好手头有个

class Timer
{
public:
explicit Timer(int tickFrequency);
virutal void onTick() const;//定时器每滴答一次此函数被自动调用一次
...
};

这个类可调整为我们需要的任何频率滴答前进,每次滴答就调用virtual函数,那我们可以重新定义那个virtual函数,执行我们的任务。

为了让Widget重新定义Timer内的virtual函数,Widget必须继承子Timer.但public继承在此并不适当。因为Widget并不是个Timer,于是

class Widget:private Timer
{
private:
void onTick()const overide
{
//处理任务
}

};

这是个不错的设计,但不值几个钱,因为private继承并非绝对必要,我们可以使用复合取而带之。如下:

class Widget
{
private:
class WidgetTimer:public Timer
{
public:
void onTick() const overide
{
//执行任务
}
...
};
WidgetTimer timer;
...
};

在这里插入图片描述

这个设计比只使用private继承要复杂一些,因为它涉及public继承和复合,并导入一个新class.主要为了告诉大家,解决设计问题的方法不只一种,我们应该多训练自己的思维,多想想其他路子。其实这里选择复合也有两个理由。
1.可以阻止derived calss 重新定义onTick.
2.可以将Widget的编译依存性降至最低。如果Widget继承Timer,当Widget被编译时Timer的定义必须可见,所以定义Widget的那个文件必须包含Timer.h。但如果WidgetTimer移出Widget之外而Widget内含一个指向WidgetTimer的指针,Widget可以只带着一个简单的WidgetTimer声明式,从而降低依存性。

在现代程序设计中,虽然许多现代编程语言已经弃用了`goto`语句,但在一些特定的编程环境中,如嵌入式系统或性能敏感的应用中,`goto`语句仍可能被使用。正确使用`goto`语句需要权衡其带来的效率提升和可能对代码清晰度造成的负面影响。以下是几点建议: 参考资源链接:[程序设计语言中的goto语句之争:历史、影响与解决方案](https://wenku.csdn.net/doc/4piyki46gb) 1. 只在代码清晰可读的情况下使用`goto`,避免使用于复杂的控制流中,以免造成维护困难。 2. 使用`goto`时,尽量在函数或代码块的局部范围内,不要跨越函数边界进行跳转,以免破坏程序的封装性和模块化。 3. 当存在多个返回点或退出点的条件语句时,可考虑使用`goto`来避免代码重复,但前提是这样的跳转能够使代码更加简洁明了。 4. 在错误处理中,如果`goto`能够提高程序的错误恢复效率,例如从多层嵌套循环中快速退出,可以适当使用。 5. 在使用`goto`的同时,应遵循适当的编程标准和最佳实践,确保在团队协作中代码的一致性和可维护性。 6. 对于有性能瓶颈的部分代码,如果通过使用`goto`能够明显提升性能,但不会显著降低代码的可读性,可以作为优化手段之一。 7. 考虑到程序的正确性证明,应避免使用`goto`来构建复杂的控制流,而是尽可能使用结构化的编程构造来确保程序逻辑的清晰。 综上所述,`goto`语句的使用应当非常谨慎,并严格限制在那些确实能够带来清晰和效率提升的场景中。对于大多数现代编程场景,推荐使用结构化的编程构造来提高代码的可读性和可维护性。更多关于`goto`语句的讨论及其在程序设计中的影响和解决方案,可以参考《程序设计语言中的goto语句之争:历史、影响与解决方案》这份资料,它提供了对`goto`语句深入的分析和全面的视角。 参考资源链接:[程序设计语言中的goto语句之争:历史、影响与解决方案](https://wenku.csdn.net/doc/4piyki46gb)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

发如雪-ty

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值