基于聚合的体系结构问题

Aggregating-based architecture issues

本文关键字：体系结构 问题 于聚      更新时间：2023-10-16

我再次需要你的帮助

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

  1. 特别的一个（基于PDF，带有自定义标题）
  2. Standart one（"原始"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（显示在应用程序菜单中），因为我需要将此方法添加到所有四个类中
也许在将来我需要从自定义文档中"提取"更多的方法
在这种情况下，这种软件体系结构似乎是一个糟糕的选择，不是吗

所以我需要找到一种重构代码的方法。我应该用继承代替聚合吗？引入接口？

通常组合比继承更可取，但它似乎不适用于您的情况。为什么不从彼此继承Viewers？制作一个具有简单功能的基础查看器，该查看器可在所有地方使用，然后从中继承专门的查看器，添加新功能。

至于菜单和与其相关的操作，它们应该表示为单独的对象。请检查命令模式。

UI可以从查看器请求可用的命令列表。每个查看器都可以在初始化或构造时填写其内部命令列表，也可以根据您的选择填写。

相关文章：