Design patterns 多格式文件转换设计模式

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

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

我不喜欢为每个可能的组合实现直接转换器的想法（对于4种格式，这是12个具有大量冗余的转换器）。我从一个“超集数据结构”开始，它包含了所有格式的所有特性，作为给定格式的导入和导出过滤器之间的链接，但我想知道是否有一种最佳实践方法来做这样的事情，或者像设计模式这样的东西，可以帮助了解，例如，导入和导出直接通信而不使用“超级格式”的体系结构

嗯，这两个项目目前因时间（和需求）不足而暂停，但我愿意学习下一次如何做得更好。这本相册为我的个人书做了它的工作，可能很快就会继续。它的代码是打开的。

我将使用一个基本的父类，它包含所有转换器共享的功能的通用实现。然后，接口的功能，可以是唯一的每个转换器，他们可以用来知道哪个转换器支持什么功能。最后是一个工厂实现，以创建所需的转换器类型

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

您是对的，基类是一个转换器。通过快速查看您的代码并做出一些假设，您将拥有的输入是您自己指定的类（例如ScribusWriter）。您可以为这些文件创建一个公共写入程序。所以我会想象这样的情况：

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);
}

公共抽象类BaseConverter{
//避免您提到的重复使用的常用方法
公共抽象void转换（XMLBuilderXML，字符串输入，T编写器）；
}

对于接口，我的想法来自于您所写的关于某些格式支持宏而其他格式不支持宏的内容。因此，一个指向宏支持的界面将帮助我们知道哪些可以和哪些不可以，并在必要时“强制”实现

---

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

如果您有多个不同格式的文件转换器，那么您可以使用Dijkstra算法找到两种文件格式之间的最短路径。此示例使用带有编程语言和编译器列表的库：

from dijkstar import Graph, find_path
graph = Graph()

for edge in [
    "C,JavaScript,Emscripten",
    "Java,JavaScript,JSweet",
    "JavaScript,Python,JS2Py",
    "Python,C++,Nuitka",
    "Python,JavaScript,Transcrypt",
    "JavaScript,PHP,js2php"
]:
    graph.add_edge(*edge.split(","))

#print a conversion path
print(find_path(graph, "JavaScript", "C++",cost_func = lambda a,b,c,d:1).edges)

---

在本例中，输入格式为

“JavaScript”

，输出格式为

“C++”

，转换路径为

['JS2Py'，'Nuitka']

您的“基本父类”是数据模型还是转换器？它读起来更像“转换器”，那么这个转换器的输入格式是什么？下一个问题：调用接口函数是什么？嗨@Danielder，我试图用一个有趣的观点详细阐述我的回答。也许更多的是旁敲侧击。可能有助于标记（许多转换器，简单的逻辑），但对于PhotoBook来说，更多的是关于少数具有复杂逻辑的转换器（每个转换都有可能丢失信息）