为了将Java 对象模型转换为XML,我使用以下设计:
对于不同类型的对象(例如原始类型、集合、null 等),我为每个对象定义了自己的转换器,它针对给定的类型进行适当的操作。通过这种方式,它可以轻松扩展,而无需向巨大的 if-else-then 结构添加代码。
转换器是通过测试对象是否完全可转换的方法以及使用优先级排序来选择的。优先级排序很重要,所以假设 aList不被 POJO 转换器转换,即使它是可转换的,使用集合转换器会更合适。
那是什么设计模式?
我只能想到与命令模式的相似之处。
为了将Java 对象模型转换为XML,我使用以下设计:
对于不同类型的对象(例如原始类型、集合、null 等),我为每个对象定义了自己的转换器,它针对给定的类型进行适当的操作。通过这种方式,它可以轻松扩展,而无需向巨大的 if-else-then 结构添加代码。
转换器是通过测试对象是否完全可转换的方法以及使用优先级排序来选择的。优先级排序很重要,所以假设 aList不被 POJO 转换器转换,即使它是可转换的,使用集合转换器会更合适。
那是什么设计模式?
我只能想到与命令模式的相似之处。
好吧,您可以首先尝试对您想做的事情进行分类(输出一个 XML 文件,将某些内容转换为某些内容)。设计模式分为三类;
在这种情况下,您有两种类型的类,一个 xml 编写器和一些转换器。xml 编写器基本上是一个构建器(它创建一个文件)
XmlWriter writer = new XmlWriter();
writer.writeHeader();
for (Item item : xmlitems) {
writer.write(convert(item));
}
writer.close();
现在,一个类到 xml 的实际转换是由几个类完成的。你提到你有一个测试类并将它们定向到特定转换器的方法。这个类可以被认为是创建某事物的一个新实例,因此它属于创建模式。
有三种类型的模式适合 IMO。
抽象工厂模式,它为创建相关或依赖对象提供了一个接口,而无需指定对象的具体类。
构建器模式,将复杂对象的构造与其表示分离,以便相同的构造过程可以创建不同的表示。
工厂方法模式,它允许类将实例化推迟到子类。
资料来源:维基百科
在我看来,任何一个都合适。构建器模式是合适的,因为实现有点像
public interface Converter {
void convert(Item item);
XmlTextNode getResult(); // get xml code
}
即你给班级一些东西,你会得到一个结果。
工厂模式是合适的,因为您将实例化推迟到其他一些类(您谈到的重定向方法)
public XmlTextNode convert(Item item) {
if (item instanceof ConcreteItem) {
return new ConcreteConverter(item).getResult();
}
throw new InvalidOperationException("Invalid convert type");
}
在任何一种情况下,返回项目的实际类型都不重要。这在一定程度上取决于您要“定义模式”的位置。是在您切换类型的方法中,还是在实际的创建/转换器类中。
再说一次,我不是这个案子的专家。