Question

我必须根据预定义的签名实现一组60个功能。它们必须是全局函数，而不是某些类的成员函数。当我实现它们时，我使用了第三方提供的一组很好的类。

我对大多数功能的实现很短，大约5到10行，并且主要处理对第三方类的不同访问。对于一些更复杂的函数，我创建了几个处理所有复杂内容的新类，我也在函数中使用它们。所有状态信息都存储在我和第三方类的静态成员中，因此我不必创建全局变量。

问题：如果我实现一个包含60个成员函数的大类，并且完成所有实现（现在在全局函数中）会不会更好？我必须编写的每个函数都只调用类中相应的成员函数。

Answer 1

所有状态信息都存储在我和第三方类的静态成员中，因此我不必创建全局变量。

这是关键点。不，他们绝对不应该上课。类被用于创建对象。在您的情况下，您可以将它们用作数据和功能的范围。但这就是名称空间已经更好地解决的问题：

namespace stuff {
    ... 60 functions ...
    namespace baz {
        ... if you want, you can have nested namespaces, to ...
        ... categorize the functions ...
    }

    namespace data {
        ... you can put data into an extra namespace if you want ...
    }
}

创建纯粹仅由静态成员组成的类是个坏主意。

Answer 2

您的代码用户真的需要这个大班吗？

如果是，请实施它。

如果不是，请不要浪费时间去实施它，不要浪费其他人强制测试它的时间，或者试图理解这个类在OOP外观中的确切作用。

Answer 3

litb可能是正确的。你甚至考虑在一堆免费函数中包装class的唯一原因是你需要附加一些自己的数据以便在你的包装器中使用。弹出我脑袋的唯一事情就是需要一个日志文件的句柄或包装器中类似的东西。

在相关的说明中，对抗using namespace stuff;的诱惑！始终使用命名空间限定来引用函数：

#include <stuff.h>
void some_function() {
    stuff::function_wrapper();
}

而不是：

#include <stuff.h>
using namespace stuff;
void some_function() {
    function_wrapper();
}

好处是，如果您需要将namespace转换为充满static方法的类，您可以轻松完成。

Answer 4

我认为“一级责任”规则应该引导你到这里来。 60个职能可能分为不同的职责，每个职能都应该分类。这也将为API的客户提供更多的OO接口，而不受全局功能的限制。

在全局函数或全局函数包装的类中实现

4 个答案: