C++三则

这是在上周review代码时注意到的三点,感觉有些意思,不妨记录下来。

如无必要,勿增虚函数

比如我们有以下关于球的类层次设计 ,其中需要判断某种球是否是可以踢的(kickable):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class Ball
{
public:
virtual bool IsKickable() = 0;
};
class Football
{
public:
virtual bool IsKickable() {returntrue;}
};
class Basketball
{
public:
virtual bool IsKickable() {returnfalse;}
};
乍一看觉得挺合理的,但仔细想想,其实IsKickable是某种球的本质静态属性,用一个虚函数来表示这种信息,是一种浪费,更加合理的方式应该是用一个数据成员和一个普通成员函数:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class Ball
{
public:
bool IsKickable(){return m_bIsKickable;}
protected:
bool m_bIsKickable;
};
class Football
{
public:
Football():bIsKickable(true){}
};
class Basketball
{
public:
Basketball():bIsKickable(false){}
};

类似这样的设计我碰到过至少两次,一次是被review,一次是review,结果都是改成了第二种我们认为比较合理的方式。

不要用 "||" 做复杂的逻辑判断

"||"是"或运算"符号,当你确实将其作为或运算时,的确很简单明了。但是有人发明了一种比较tricky的方法来使用它。举个例子,我们的程序可能有三种状态:A, B,或者C,现在有一个变量bOk,如果程序当前状态为C的话,bOk必须为true,如何来assert? 一般比较直观的做法是:
1
if(IsC()) assert(bOk);
 但是有人觉得有个if判断比较麻烦,于是发明了:
1
assert(IsA() || IsB() || bOk);
逻辑理解为:如果不是A也不是B,那么bOk必须为true。 虽然代码简化成只有单个语句,但是,这对理解却带来了挑战。
我们一般不推荐用这种不直观的方式来做判断。

纯虚函数与默认实现

有一个基类,我们期望它是一个抽象类,但同时我们又期望其虚函数都有默认实现。这其实一个语法层面的问题:我们是可以把一个虚函数设为纯虚的同时提供默认实现的。(但一开始以为不行,想去把构造函数设为pretected来达到类似的效果,但这样从概念上来讲就不是很合理了)对于这种情况,我想也没必要把所有函数设为纯虚,找一个典型,如把析构函数设为纯虚并提供默认实现:
1
2
3
4
5
6
7
8
9
10
11
class Base
{
public:
virtual~Base() =0;
};
Base::~Base() {printf("~Base()\n");}
class Derive: public Base
{
public:
virtual~Derive(){printf("~Derive()\n");}
}
这样,基类就已经是一个抽象类了,应该是一个可以接受的方案。
posted @   lzprgmr  阅读(855)  评论(0编辑  收藏  举报
编辑推荐:
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
阅读排行:
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· [AI/GPT/综述] AI Agent的设计模式综述

黄将军

点击右上角即可分享
微信分享提示