基于聚合的架构问题

Question

我又需要你的帮助了。

我有一个文档查看器应用程序，它可以读取两种不同类型的文档：

1. 特别篇（基于PDF，带自定义页眉）
2. 标准一（“原始”PDF）。

使用原始 PDF 查看器的行为应该与其他任何查看器一样。
使用自定义 - 在打开期间执行一些附加操作，
这些操作不适用于原始 PDF。
这些操作稍后应仅在应用程序的菜单中可用。并且仅适用于自定义文档。

项目 OOP 架构（由其他人设计）如下所示：

class GenericDocument
    class PdfLibDocument
        class CustomDocumentHighLevel
            class CustomDocumentLowLevel

即每个较高级别的类都包含较低级别的作为成员：

class GenericDocument
{
   SmartPointer< PdfLibDocument > m_document;
   ...
};

等等。

自定义文档有很多特定的功能：

class CustomDocumentLowLevel
{
     public:
        void DoSomeBlackMagic();
        ...
        // Another black magic
};

问题出现了，然后我需要将一些低级方法从CustomDocumentLowLevel“拉”到GenericDocument（显示在应用程序菜单中）-因为我需要将此方法添加到 ALL FOUR 上课！
并且可能在将来我需要从自定义文档中“提取”更多方法。
看起来这种软件架构在这种情况下是不好的选择，不是吗？

所以我需要找到一种方法来重构这段代码。我应该用继承代替聚合吗？介绍接口？

Answer 1

通常组合优于继承，但它似乎不适用于您的情况。为什么不互相继承查看器？制作一个具有简单功能的基本查看器，在所有地方都可用，然后从它继承专门的查看器，添加新功能。

至于菜单和动作，与其相连，它们应该被表示为一个单独的对象。检查Command 模式。

UI 可以向您的查看器请求可用的命令列表。每个查看器都可以在初始化或构造或您选择的任何内容时填写其内部命令列表。