design-patterns - 多格式文件转换设计模式

Question

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

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

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

好吧，这两个项目目前由于缺乏时间(和需求)而暂停，但我愿意学习下次如何做得更好。这本相册为我的个人书完成了它的工作，并且可能很快会继续下去。它的代码在 GitHub .

Answer 1

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

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

你是对的，基类是一个转换器。通过快速查看您的代码并做出一些假设，您将拥有的输入是您自己指定的类(例如，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);
}

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

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