关于仅包含静态成员的类,我看到有多个人声称这是一种不好的模式,而且它从来不是解决问题的最佳方案。
在C++中,只包含静态成员的实用程序类是否为反模式?上被接受并得到最高票数的答案主张使用命名空间,并总结道:
“对我来说,最明显的答案是:因为我们不需要面向对象来实现这个。”
这让我感到困惑,原因有几个。它似乎是在谈论仅包含静态成员函数的类,而不是包含静态数据和静态函数的类。仅包含静态成员函数的类确实可以用命名空间内的全局函数替换,但如何替换同时包含静态函数和静态数据的类呢?
在一个命名空间内有函数和全局变量?你如何确保
另一件让我困惑的事情是,我觉得只有静态成员的类在C++的书籍和库中是相当常见的。 SFML的
那么应该怎么想呢?只有静态成员的类是不好的设计/不良实践吗?还是它们在某些情况下有其存在的意义?
“对我来说,最明显的答案是:因为我们不需要面向对象来实现这个。”
这让我感到困惑,原因有几个。它似乎是在谈论仅包含静态成员函数的类,而不是包含静态数据和静态函数的类。仅包含静态成员函数的类确实可以用命名空间内的全局函数替换,但如何替换同时包含静态函数和静态数据的类呢?
struct Foo
{
static void add5()
{
s_x += 5;
}
static const int& getX()
{
return s_x;
}
private:
static int s_x;
};
int Foo::s_x{ 0 };
在一个命名空间内有函数和全局变量?你如何确保
s_x
不能被外部代码直接访问和修改?另一件让我困惑的事情是,我觉得只有静态成员的类在C++的书籍和库中是相当常见的。 SFML的
sf::Mouse
只有静态成员。
游戏编程模式多次使用只有静态成员的类,甚至在单例模式章节中用术语“静态类”来引用它。而服务定位器章节本质上就是一个只有静态成员的类。那么应该怎么想呢?只有静态成员的类是不好的设计/不良实践吗?还是它们在某些情况下有其存在的意义?
struct Foo
也是一种类型,这意味着它可以在类型上下文中使用,比如模板参数。 - Drew Dormann