C++高级编程：构建高效稳定接口与深入对象设计技巧

建立稳定接口

类是C++中的主要抽象单位。你应该将抽象原则应用于你的类，尽可能将接口与实现分离。具体来说，你应该使所有数据成员私有，并可选择性地提供getter和setter方法。这就是SpreadsheetCell类的实现方式：m_value是私有的，而公共的set()方法设置值，getValue()和getString()方法检索值。

使用接口和实现类

即便采取了上述措施和最佳设计原则，C++语言本质上对抽象原则不友好。其语法要求你将公共接口和私有（或受保护的）数据成员及方法组合在一个类定义中，从而将类的一些内部实现细节暴露给其客户端。这样做的缺点是，如果你需要在类中添加新的非公开方法或数据成员，所有使用该类的客户端都必须重新编译。这在大型项目中可能成为负担。

好消息是你可以让你的接口更加干净，并隐藏所有实现细节，从而实现稳定的接口。坏消息是这需要一些编码工作。基本原则是为你想编写的每个类定义两个类：接口类和实现类。实现类与你在不采取此方法时编写的类相同。接口类提供与实现类相同的公共方法，但它只有一个数据成员：指向实现类对象的指针。这被称为pimp习语，私有实现习语，或桥接模式。接口类的方法实现简单地调用实现类对象上的等效方法。

这样的结果是，无论实现如何改变，都不会影响公共接口类。这减少了重新编译的需要。如果实现（仅实现）发生变化，使用接口类的客户端无需重新编译。请注意，这种习语仅在单一数据成员是指向实现类的指针时才有效。如果它是按值数据成员，则在实现类定义发生变化时，客户端必须重新编译。

要在Spreadsheet类中使用此方法，请定义以下公共接口类，称为Spreadsheet。

module;
#include <cstddef>
export module spreadsheet;
export import spreadsheet_cell;
import <memory>;

export class SpreadsheetApplication { };

export class Spreadsheet {
public:
    Spreadsheet(const SpreadsheetApplication& theApp, size_t width = MaxWidth, size_t height = MaxHeight);
    Spreadsheet(const Spreadsheet& src);
    Spreadsheet(Spreadsheet&&) noexcept;
    ~Spreadsheet();
    Spreadsheet& operator=(const Spreadsheet& rhs);
    Spreadsheet& operator=(Spreadsheet&&) noexcept;
    void setCellAt(size_t x, size_t y, const SpreadsheetCell& cell);
    SpreadsheetCell& getCellAt(size_t x, size_t y);
    size_t getId() const;
    static const size_t MaxHeight { 100 };
    static const size_t MaxWidth { 100 };
    void swap(Spreadsheet& other) noexcept;

private:
    class Impl;
    std::unique_ptr<Impl> m_impl;
};

export void swap(Spreadsheet& first, Spreadsheet& second) noexcept;

实现类Impl是一个私有嵌套类，因为除了Spreadsheet类之外，没有人需要了解这个实现类。现在，Spreadsheet类只包含一个数据成员：指向Impl实例的指针。公共方法与旧的Spreadsheet类相同。

掌握类和对象

嵌套的Spreadsheet::Impl类在spreadsheet模块的实现文件中定义。它应该对客户端隐藏，因此不导出Impl类。Spreadsheet.cpp模块实现文件如下开始：

module;
#include <cstddef

>
module spreadsheet;
import <utility>;
import <stdexcept>;
import <format>;
import <algorithm>;
using namespace std;

// Spreadsheet::Impl类定义。
class Spreadsheet::Impl {
    /* 为简洁起见省略 */
};

// Spreadsheet::Impl方法定义。
Spreadsheet::Impl::Impl(const SpreadsheetApplication& theApp, size_t width, size_t height)
: m_id { ms_counter++ }
, m_width { min(width, Spreadsheet::MaxWidth) }
, m_height { min(height, Spreadsheet::MaxHeight) }
, m_theApp { theApp }
{
    m_cells = new SpreadsheetCell*[m_width];
    for (size_t i{ 0 }; i < m_width; i++) {
        m_cells[i] = new SpreadsheetCell[m_height];
    }
}
// 其他方法定义省略以简洁。

Impl类几乎具有与原始Spreadsheet类相同的接口。对于方法实现，需要记住Impl是一个嵌套类；因此，你需要指定作用域为Spreadsheet::Impl。所以，对于构造函数，它变成了Spreadsheet::Impl::Impl(...)。

由于Spreadsheet类具有指向实现类的unique_ptr，因此Spreadsheet类需要有用户声明的析构函数。由于我们不需要在此析构函数中执行任何操作，因此可以在实现文件中将其默认为：

Spreadsheet::~Spreadsheet() = default;

事实上，它必须在实现文件中默认，而不是直接在类定义中。原因是Impl类仅在Spreadsheet类定义中前向声明；也就是说，编译器知道将会有一个Spreadsheet::Impl类出现在某处，但此时它还不知道定义。因此，你不能在类定义中默认析构函数，因为编译器会尝试使用尚未定义的Impl类的析构函数。在这种情况下，对其他方法进行默认操作时也是如此，例如移动构造函数和移动赋值运算符。

实现Spreadsheet方法

Spreadsheet类的方法实现，如setCellAt()和getCellAt()，只是将请求传递给底层的Impl对象：

void Spreadsheet::setCellAt(size_t x, size_t y, const SpreadsheetCell& cell) {
    m_impl->setCellAt(x, y, cell);
}

SpreadsheetCell& Spreadsheet::getCellAt(size_t x, size_t y) {
    return m_impl->getCellAt(x, y);
}

Spreadsheet的构造函数必须构造一个新的Impl以执行其工作：

Spreadsheet::Spreadsheet(const SpreadsheetApplication& theApp, size_t width, size_t height) {
    m_impl = make_unique<Impl>(theApp, width, height);
}

Spreadsheet::Spreadsheet(const Spreadsheet& src) {
    m_impl = make_unique<Impl>(*src.m_impl);
}

拷贝构造函数看起来有些奇怪，因为它需要从源Spreadsheet复制底层的Impl。拷贝构造函数接受一个Impl的引用，而不是指针，所以你必须解引用m_impl指针来获取对象本身。

Spreadsheet赋值运算符必须同样将赋值传递给底层的Impl：

Spreadsheet& Spreadsheet::operator=(const Spreadsheet& rhs) {
    *m_impl = *rhs.m_impl;
    return *this;
}

赋值运算符中的第一行看起来有些奇怪。Spreadsheet赋值运算符需要将调用转发给Impl赋值运算符，这只在你复制直接对象时运行。通过解引用m_impl指针，你强制执行直接对象赋值，这导致调用Impl的赋值运算符。

swap()方法简单地交换单一数据成员：

void Spreadsheet::swap(Spreadsheet& other) noexcept {
    std::swap(m_impl, other.m_impl);
}

这种技术将接口与实现真正分离，是非常强大的。虽然一开始有些笨拙，但一旦习惯了，你会发现它很自然易用。然而，在大多数工作环境中，这不是常见做法，所以你可能会遇到同事的一些抵触。支持这种做法的最有力论据不是分离接口的美学，而是如果类的实现发生变化，构建时间的加速。

注意

使用稳定的接口类，可以减少构建时间。将实现与接口分离的另一种方法是使用抽象接口，即只有纯虚方法的接口，然后有一个实现该接口的实现类。这是下个主题。