Question

我有时遇到过，主要是在处理旧代码时，一个类只是将调用转发给另一个类的情况。想象一下，有一个旧的控制器可以控制某些东西，但其中一些可以用于新的类。现在，旧控制器将调用新的类接口。

实施例。

class Controller {
  public:
    void addObject(const std::string & id,
      const Object * obj) {
      m_Wrk.addObject(id, obj);
    }
  private:
    Worker m_Wrk;
};

class Worker {
  public:
    void addObject(const std::string & id,
      const Object * obj) {
      //do actual adding
    }
};

现在，在考虑测试软件时，可能需要在两个类中测试接口，并且控制器中的接口更难，因为它主要不是检查控制器测试中的工作者更改所必需的。

这种用法特别糟糕，或者可以在现有代码中使用这种设计，如上所述。

由于

Answer 1

很难回答这段代码是好还是坏 - 这取决于具体情况。有问题的代码（include字段应该是指针的事实除外）是PImpl模式，这是一种bridge模式。此模式用于拆分抽象和实现，以便它们可以独立更改。

例如，如果你编写了一个C ++库，并且你想提供一个稳定的ABI，如果公共接口没有变化就不会改变，你可以放置m_Wrk接口在标题中，与Controller类的前向声明一起，并将Worker的接口和实现放在Worker文件中。当.cpp更改时，Worker ABI保持不变。如果实现细节直接放在Controller类中，则ABI可能会更改。

此外，这种模式（通常是Bridge）允许您使用给定的抽象的不同实现，因此，就Liskov替换而言，可以根据接口扩展和继承来分离继承。

此外，如果Controller实现与Controller相同的接口，将来它可以实现一些额外的行为，例如proxy模式。

如果其中一种情况发生在您的项目中（或可能在将来发生），那么它可能是一个很好的代码。如果不是，那只是一种不必要的并发症。

类接口重复

1 个答案: