开发者

Design Paradigm for instantiating object from XML file

For a uni assignment I'm writing a java program which needs to save and load an object hierarchy to XML file开发者_StackOverflows. For example, the program creates a Zoo class with a list of subclasses of Animals, saves this to XML, and is loaded again the next time the user starts the program.

The file might look like

<Zoo>
    <Animals>
        <Lion>
            <name>Leo</name>
            <age>5</age>
            <roar>fearsome</roar>
        </Lion>
        <Elephant>
            <name>Dumbo</name>
            <age>10</age>
            <ears>let him fly</ears>
        </Elephant>
    </Animals>
</Zoo>

There is a low, finite number of subclasses of Animal I need to support (~5). Each subclass of animal has individual attributes (like Ears and Roar). I'm confused as to what the best design pattern for object creation and file creation is.

Currently, I have a class, XMLCreator, with methods such as void createZooElement(Zoo), void createLionElement(Lion) etc etc, and an XMLReader class with private Zoo createZoo(File), private Lion createLionObject(Element).

Is this a good way to go if this were code you expect to be maintained by others in the future? Or should each object have a constructor method which takes a File/Element as a parameter and another method which returns a File/XMLElement? Which is the way with the most encapsulation/maintainability?


I would just use JAXB, which allows marshalling a tree of objects (of annotated classes) to XML, and unmarshalling XML to a tree of objects. There are other Object to XML APIs, but JAXB comes with Java SE and works well.


Using XStream, you can serialize most Java objects without any mapping. Object names become element names in the XML produced, and the strings within classes form the element content of the XML. The classes that you serialize with XStream don't need to implement the Serializable interface. XStream is a serialization tool and not a data binding tool, which means that it doesn't perform class generation from an XML or XML Schema Definition (XSD) file


In my opinion, you want either the Builder pattern, or the Factory pattern. Check out wikipedia for more details. I'd go with the Factory pattern because I'm more familiar with it. Rather than name it XMLCreator, I'd call it AnimalFactory:

public class AnimalFactory () {
    private static final AnimalFactory instance = new AnimalFactory ();

    // I make this private so that I can be sure there is only one instance
    // of the object. This is another pattern, the `Singleton`
    private AnimalFactory () {};

    // This is how you would access the instance
    public static AnimalFactory getInstance () { return instance; }

    // This is where you create the animal instances.
    public Lion getLion () {...}
    public Elephant getElephant () {...}
}


Many good choices here. For xml data binding.

XMLBean needs XML schema.

JiBX, castor, need a mapping file.


You need SAXParser with ContentHandler.

You will have to implement startElement... endElement... and few others.

You can change your parsing strategy reading the element in startElement methods.

It should be easy, I believe.

This article should a nice read.


Additionally if you keep creating methods like void createZooElement(Zoo) you will be ended up with unmanageable hundreds of methods in end of the day.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜