多格式文件转换设计模式

Question

过去，我曾两次尝试实现多格式转换器。一个是标记转换器，应该能够转换 GitHub、StackOverflow、MoinMoin、MediaWiki 等。另一个是相册转换器，目前将 ifloror 转换为 scribus，但应该支持至少另外两种相册格式以及 pdf。

问题总是相同的：不同的格式有不同的特征。例如：MediaWiki 和 MoinMoin 对宏的理解不同，而大多数其他标记语言不支持宏。或者 ifolor 有一些边框格式很难在 scribus 中实现，而且看起来也不好看。

我不喜欢为每种可能的组合实现直接转换器的想法（对于 4 种格式，这是 12 个具有大量冗余的转换器）。我从“超集数据结构”开始，它包含所有格式的所有功能，作为给定格式的导入和导出过滤器之间的链接，但我想知道是否有最佳实践方法来执行此类操作或类似操作了解设计模式可能会有所帮助，例如导入和导出直接通信而无需“超级格式”的架构？

好吧，由于缺乏时间（和需求），这两个项目目前已暂停，但我愿意学习下次如何做得更好。这本写真集为我的个人书完成了它的工作，并且可能很快就会继续。它的代码位于GitHub上。

Answer 1

我会选择一个基父类，其中包含所有转换器共享的功能的通用实现。然后，每个转换器的功能接口可能是唯一的，它们可用于了解哪个转换器支持哪些功能。最后是一个工厂实现来创建所需的转换器类型。

在评论后编辑以更好地解释自己：

你是对的，基类是一个转换器。快速查看您的代码并做出一些假设，您将获得的输入是您自己指定的类（例如，ScribusWriter）。您可以为这些创建一个通用的 Writer。所以我会想象这样的事情：

public abstract class BaseConverter {

    // common methods to avoid the redunduncies you mentioned

    public abstract <T extends BaseWritter> void convert(XmlBuilder xml, String input, T writer);
}

对于接口，我从您所写的有关某些格式支持宏而其他格式不支持的内容中想到了这一点。因此，指向宏支持的接口将帮助我们知道哪些可以做，哪些不可以，并在必要时“强制”实现。

我的建议是，您使用继承来根据特征/功能对类型进行分类，并避免常见功能的冗余。