对于我的库，我想公开一个干净的公共(public) API，它不会分散实现细节的注意力。但是，正如您所了解的那样，这些细节甚至会泄露到公共(public)领域:一些类具有有效的公共(public)方法，可供库的其余部分使用，但对 API 的用户来说不是很有用，因此不要不需要成为其中的一部分。公共(public)代码的简化示例:

class Cookie;

class CookieJar {
public:
    Cookie getCookie();
}

class CookieMonster {
public:
    void feed(CookieJar cookieJar) {
        while (isHungry()) {
            cookieJar.getCookie();
        }
    }

    bool isHungry();
}

CookieJar 的 getCookie() 方法对库的用户没有用处，他们大概不喜欢 cookie。然而，CookieMonster 使用它来喂养自己，当给定一个时。

有一些习语可以帮助解决这个问题。 Pimpl 惯用语提供了隐藏类的私有(private)成员的方法，但几乎没有掩饰不应成为 API 一部分的公共(public)方法。也可以将它们移动到实现类中，但是您需要提供对它的直接访问以供库的其余部分使用。这样的标题看起来像这样:

class Cookie;
class CookieJarImpl;

class CookieJar {
public:
    CookieJarImpl* getImplementation() {
        return pimpl.get();
    }
private:
    std::unique_ptr<CookieJarImpl> pimpl;
}

如果您真的需要阻止用户访问这些方法，它会很方便，但如果这只是一种烦恼，这就没什么用了。事实上，新方法现在比上一个更无用，因为用户无权访问 CookieJarImpl 的实现。

另一种方法是将接口(interface)定义为抽象基类。这可以明确控制公共(public) API 的一部分。任何私有(private)细节都可以包含在该接口(interface)的实现中，用户无法访问。需要注意的是，由此产生的虚拟调用会影响性能，甚至比 Pimpl 习惯用法更严重。更简洁的 API 的交易速度对于应该是高性能库的东西来说并不是很有吸引力。

为了详尽无遗，另一种选择是将有问题的方法设为私有(private)，并在需要从外部访问它们的地方使用友元类。然而，这也使目标对象也可以访问真正的私有(private)成员，从而在某种程度上破坏了封装。

到目前为止，对我来说最好的解决方案似乎是 Python 方式:不要试图隐藏实现细节，只需适本地命名它们，这样它们就很容易被识别为不是公共(public) API 的一部分，并且不会分散常规用法。想到的命名约定是使用下划线前缀，但显然这样的名称是为编译器保留的，不鼓励使用它们。

是否有任何其他 C++ 命名约定来区分不打算从库外使用的成员？或者您会建议我使用上述替代方案之一还是我错过的其他方案？

最佳答案

回答我自己的问题:这个想法基于接口(interface) - 实现关系，其中公共(public) API 被明确定义为接口(interface)，而实现细节驻留在扩展它的单独类中，用户无法访问，但可以访问图书馆的其余部分。

在使用 CRTP 实现静态多态性的过程中，作为 πìντα ῥεῖ 建议避免虚拟调用开销，我意识到对于这种设计实际上根本不需要多态性，只要只有一种类型会实现接口(interface)。这使得任何类型的动态调度都毫无意义。在实践中，这意味着扁平化所有你从静态多态性中获得的丑陋模板，并以非常简单的东西结束。没有 friend ，没有模板，(几乎)没有虚拟电话。让我们将其应用于上面的示例:

这是 header ，仅包含带有示例用法的公共(public) API:

class CookieJar {
public:
    static std::unique_ptr<CookieJar> Create(unsigned capacity);

    bool isEmpty();
    void fill();

    virtual ~CookieJar() = 0 {};
};

class CookieMonster {
public:
    void feed(CookieJar* cookieJar);
    bool isHungry();
};

void main() {
    std::unique_ptr<CookieJar> jar = CookieJar::Create(20);
    jar->fill();
    CookieMonster monster;
    monster.feed(jar.get());
}

这里唯一的变化是将 CookieJar 变成一个抽象类并使用工厂模式而不是构造函数。

实现:

struct Cookie {
    const bool isYummy = true;
};

class CookieJarImpl : public CookieJar {
public:
    CookieJarImpl(unsigned capacity) :
        capacity(capacity) {}

    bool isEmpty() {
        return count == 0;
    }

    void fill() {
        count = capacity;
    }

    Cookie getCookie() {
        if (!isEmpty()) {
            count--;
            return Cookie();
        } else {
            throw std::exception("Where did all the cookies go?");
        }
    }

private:
    const unsigned capacity;
    unsigned count = 0;
};

// CookieJar implementation - simple wrapper functions replacing dynamic dispatch
std::unique_ptr<CookieJar> CookieJar::Create(unsigned capacity) {
    return std::make_unique<CookieJarImpl>(capacity);
}

bool CookieJar::isEmpty() {
    return static_cast<CookieJarImpl*>(this)->isEmpty();
}

void CookieJar::fill() {
    static_cast<CookieJarImpl*>(this)->fill();
}

// CookieMonster implementation
void CookieMonster::feed(CookieJar* cookieJar) {
    while (isHungry()) {
        static_cast<CookieJarImpl*>(cookieJar)->getCookie();
    }
}

bool CookieMonster::isHungry() {
    return true;
}

总体而言，这似乎是一个可靠的解决方案。它强制使用工厂模式，如果您需要复制和移动，则需要以与上述类似的方式自己定义包装器。这对于我的用例来说是可以接受的，因为无论如何我需要使用它的类都是重量级资源。

我注意到的另一件有趣的事情是，如果你觉得真的很冒险，你可以用 reinterpret_casts 替换 static_casts 并且只要接口(interface)的每个方法都是你定义的包装器，包括析构函数，你就可以安全地将任意对象分配给一个你定义的接口(interface)。可用于制作不透明 wrapper 和其他恶作剧。

关于C++ API 设计 : Clearing up public interface，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38855926/