Question

但我不知道我是否应该选择静态方法，只是标题，类或其他东西？

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

我想添加以下功能：

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

Answer 1

不要把它们放在课堂上;只需在命名空间范围内使它们成为非成员函数。

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

Answer 2

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

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

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

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

Answer 3

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

如果你想提供类的stringer逻辑分组，将它们作为类的静态成员函数没有真正的危害 - 但我认为你没有理由拥有像MapRGB()和{CopyString()这样的函数{1}}需要成为同一个班级的成员。

Answer 4

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

我会尝试使用有意义的命名空间 - 将MapRGB和CopySstring放在一起毫无意义。如果你真的需要两者，并且真的没有任何其他处理字符串或RGB映射的函数，那么将它们放入“utillity”命名空间可能是有意义的，但是如果你使用它们，看起来你有更多的字符串“东西”和一些更“颜色”的东西，并且可能从每个都有一个命名空间中受益。

Answer 5

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

C ++：如何设计实用程序类？

5 个答案: