c++ - 将一个模块的所有代码放在一个接口(interface)后面。好主意与否？

Question

我有几个模块(主要是 C)需要重新设计(使用 C++)。目前主要存在的问题是:

• 应用程序的许多部分都依赖于模块的功能
• 应用程序的某些部分可能想要否决模块的行为

我在考虑以下方法:

• 重新设计模块，使其具有清晰的现代类结构(使用接口(interface)、继承、STL 容器……)
• 编写可用于访问模块的任何功能的全局模块接口(interface)类
• 编写此接口(interface)的实现，将接口(interface)方法简单地映射到接口(interface)中正确类的正确方法

当前直接使用该模块的 C 函数的应用程序中的其他模块，应通过此接口(interface)的[实现]。这样一来，如果应用程序想要更改模块某个功能的行为，它只需继承此默认实现并否决它想要的任何功能。

一个例子:

• 假设我完全重新设计了我的模块，这样我就有了像这样的类:Book、Page、Cover、Author……所有这些类都有很多不同的方法。
• 我制作了一个名为 ILibraryAccessor 的全局接口(interface)，其中包含许多纯虚拟方法
• 我做了一个默认实现，称为 DefaultLibraryAccessor，而不是简单地将所有方法转发到正确类的正确方法，例如
  • DefaultLibraryAccessor::printBook(book) 调用 book->print()
  • DefaultLibraryAccessor::getPage(book,10) 调用 book->getPage(10)
  • DefaultLibraryAccessor::printPage(page) 调用 page->print()
• 假设我的应用程序有 3 种窗口
  • 第一个允许所有功能，作为一个应用程序我想允许它
  • 第二个也允许所有功能(内部)，但我想从应用程序中防止打印单独的页面
  • 第三个也允许所有功能(内部)，但我想从应用程序中阻止打印某些类型的书籍
• 构建窗口时，应用程序将 ILibraryAccessor 的实现传递给窗口
  • 第一个窗口将获得 DefaultLibraryAccessor，允许一切
  • 我将向第二个窗口传递一个特殊的 MyLibraryAccessor，在 MyLibraryAccessor 中，我将否决 printPage 方法并让它失败
  • 我将向第三个窗口传递一个特殊的 AnotherLibraryAccessor，在 AnotherLibraryAccessor 中，我将否决 printBook 方法并在我调用 book->print() 之前检查图书的类型。

这种方法的优点是，如示例所示，应用程序可以否决它想要否决的任何方法。缺点是我得到了一个相当大的接口(interface)，并且对于所有想要访问这个其他模块的模块来说，类结构完全丢失了。

好不好？

Answer 1

您可以用嵌套接口(interface)表示类结构。例如。而不是 DefaultLibraryAccessor::printBook(book)，有 DefaultLibraryAccessor::Book::print(book)。否则它对我来说看起来是个不错的设计。