7

但我不知道我是否应该使用静态方法，只是一个标题、一个类或其他东西？

什么是最佳实践？但是，我不想拥有实用程序类的实例。

我想添加如下功能：

Uint32 MapRGB (int r, int g, int b);
const char* CopyString(const char* char);
// etc. You know: utility methods...
4

5 回答 5

27

不要把他们放在一个班级里；只需在命名空间范围内将它们设为非成员函数即可。

没有规则说每个函数都必须是某个类的成员函数。

于 2010-06-18T15:11:25.887 回答
3

一个因素是是否将它们放在一个类中，或者只是将它们作为 nomembers 放在命名空间中（在 Java 中，您必须使用一个类，但 C++ 提供命名空间）。

如果您确实将其设为类成员，那么您必须对每个函数做出的最重要决定是它是否需要或应该影响任何未通过其参数和返回值接收或传递的状态。如果没有，则应该进行static，因为您不会使用“this”隐藏参数。

使用类而不是命名空间的一个论点是，您的实用程序类是否可能需要为其实现调用其他方法（例如，在递归、复杂计算等情况下）。然后，您可以制作您的方法static public，以及它所实施的任何东西static private。我使用 C++ 已经很多年了，但我认为你不能在命名空间中“隐藏”非成员函数（如果我错了，请有人纠正我）。

在设计函数接口方面，考虑参数的数量。如果传入的参数太多（特别是如果它们具有相似的类型并且有些相关），您可能需要考虑使用其他类型而不是传递多个参数。例如calculateVolume(int x, int y, int z)，您可能想要执行类似的操作，而不是calculateVolume(Point3D)。同样，在您的情况下，使用 RGB 类。这可能看起来很傻，但它可以节省一些烦人的错误（例如，如果您有采用整数和 RGB 的函数）和时间（如果您必须将值传递给其他函数）。您可以创建静态工厂方法，以便在传递参数时更容易创建这些类型。例如：doSomethingWithColor(RGB.create(20,30,40))

于 2010-06-18T15:13:47.893 回答
1

如果它们在逻辑上不属于某个类，则可能没有理由让一个类来包装这些函数。在这种情况下，您可以让它们成为免费功能。将它们包含在命名空间中以帮助避免名称冲突可能是合适的。

如果你想为类提供一个更严格的逻辑分组，让它们成为类的静态成员函数并没有真正的害处——但我认为你没有理由拥有类似的函数MapRGB()并且CopyString()需要成为同一个类的成员。

于 2010-06-18T15:12:42.773 回答
1

如果您只想将函数组合在一起，而不是创建组的实例，那么您可能应该考虑将它们放入命名空间而不是类中。

不过，我会尝试使用有意义的名称空间——将 MapRGB 和 CopySstring 放在一起几乎没有意义。如果你真的需要两者，并且真的没有任何其他处理字符串或 RGB 映射的函数，将它们放入“实用程序”命名空间可能是有意义的，但如果你正在使用它们，似乎你有一些更多的字符串“东西”和更多的“颜色”东西，并且可能会受益于每个都有一个命名空间。

于 2010-06-18T15:14:11.043 回答
1

我通常有一个名为“util”的.a（Windows 上的.lib）被链接进来。但是，通常一个“util”类是坏消息，它引入了一个破坏标准面向对象设计的依赖关系。现在，如果您尝试提取一个类以在不同的项目中重用，那么您的 util 库上就有数以千计的隐藏依赖项。基本上，它很有用，但请尽量避免将东西放在那里。

于 2010-06-18T15:15:28.437 回答