基本上我今天发现自己写了很多代码,如下所示:
#define VAL_1 0
#define VAL_2 1
class A {
public:
void memberA();
void memberB();
...
void write(uin32_t address);
}
void
A::
memberA() {
this->write(VAL_1);
}
void
A::
memberB() {
this->write(VAL_2);
}
...
所以基本上,我有一些“漂亮”的名字memberA
,memberB
用于某些任务,它实际上只使用不同的参数调用相同的函数write
。使用我的类的代码不一定知道值VAL_0
和VAL_1
。 memberA
或memberB
背后的实施细节也没有,尽管write
可能会在某个时候公开。
基本上,现在我一遍又一遍地重复同一行代码this->write(...)
。我正在寻找绕过这一步的解决方案,并立即调用相应的写入。一种函数参数的传递,有点像基类中的C ++构造函数,可能带有匹配的参数:
#define VAL_1 0
#define VAL_2 1
class A {
public:
bool memberA() : write(VAL_1);
bool memberB() : write(VAL_2);
...
bool write(uin32_t address);
}
我想知道Boost.Bind中是否有某些内容或某些聪明的模板编码可以让我实现这种或那种东西?
谢谢,
FROB
答案 0 :(得分:4)
如果你在类定义中内联memberX
函数,并且如果你避免使用多余的this
引用,那么你没有太多的额外写入:
您想要的(不正确的)语法:
bool memberA() : write(VAL_1);
实际(正确)语法:
bool memberA() { return write(VAL_1); }
如果您想最小化重复代码,可以使用预处理器:
#define F(l, n) bool l() { return write(n); }
F(memberA, VAL_1)
F(memberB, VAL_2)
#undef F
此外,您可以使用预处理程序令牌粘贴操作符##
:
#define F(l, n) bool member##l() { return write(VAL_##n); }
F(A, 1)
F(B, 2)
#undef F
答案 1 :(得分:2)
如果没有完全理解你所追求的是什么(我对涉及构造函数的最后一部分感到困惑),我认为你可能会努力使你的客户更容易理解语法。
......简单地说:
class A {
public:
enum Value {val1, val2, val3, val4, etc};
bool write(Value val);
};
你试图建立一个更简单的语法是好的,但你也必须避免整体的危险。单片类是我强烈认为是面向对象设计中最常见的错误之一。 Sutter详细介绍了C++ Coding Standards
和getw:http://www.gotw.ca/gotw/084.htm。
如果你有一个包含100个成员函数的类,你可能有大约80个。
^想一想这句话。当你有这么多功能时,你的课程往往变得越来越难以管理。它还邀请其他开发人员不断向您的类添加越来越多的内容,以便其设计永远不会完成。结果是永无止境的阶级,随着每个开发周期的增长而增长,并且看不到尽头。这很容易成为错误,效率低下,持续的公共接口修订,单元测试中断的源头,并且它可能违背您的类的一般重用和灵活性。如果每个值都有一个单独的函数,你可以传递给另一个函数,那么你就会危险地进入那个领域。
尝试太难以避免语法冗余通常是一个错误。不幸的是,在某些情况下C ++只需要更长的语法(使用C ++ 11会更好)。您应该尝试优化的是逻辑冗余。这里使用各种值调用write方法不涉及逻辑冗余,并且语法开销几乎不比为每个可能传递给写入的值调用不同的函数。
如果这些函数只是简化了传递各种值的语法,那么你必须认识到,如果你在生产环境中,你还要使用更多的函数来扩展类的公共接口,你可能需要单独记录和教学。努力少花钱多办事,我觉得你会好多了。
尽量将这个整体主义的方面作为优先考虑。您甚至可以将命名常量从类定义中提升为非成员,如下所示:
class A {
bool write(uint32_t address);
};
// elsewhere
static const uint32_t address_val1 = ...;
static const uint32_t address_val2 = ...;
static const uint32_t address_val3 = ...;
这个设计实际上并没有什么问题,事实上,它有更多理想的工程特性,而不是你有更多类成员,因为它与你的类完全分离,使得该类的维护更容易,其界面更简单到教导和记录,更有可能达到合理完成状态。