0

I have a class which is called TestPlan (to put it simple, let's assume that it's a usual java bean).

I need to store TestPlan instances in xml-files (1 instance per file). The most appropriate way to do it which I can see is using another class which should do only xml-related work.

It'll have methods like:

public TestPlan parseTestPlanXml(InputStream xmlFile) {
    TestPlan testPlan = new TestPlan();
    //parse xmlFile and set testPlan fields via setters
    return testPlan;
}

public OutputStream writeTestPlanXml(TestPlan testPlan) {
    //the actual implementation just copies the original xmlFile, 
    //makes necessary modifications 
    //and writes it to ByteArrayOutputStream
    ...
}

Which name would you suggest for this class? (btw, if you can also suggest better names for these 2 methods then don't hesitate to do that).

Thanks!

Roman
  • 64,384
  • 92
  • 238
  • 332
  • writeTestPlanXml _returns_ an OutputStream!? – SoftMemes Oct 23 '10 at 21:43
  • @Freed: I don't know exacly yet. TestPlanXml should be sent over the net after 'saving'. If I'll see the necessity to store it on the local machine as well as on the remote one then this method will save an xml file and another method will just sent the file contents over the net. – Roman Oct 23 '10 at 21:46
  • either way, your write function will have to write to _something_, no? What you have now is a function returning a stream that someone else can write to, which does not make sense to me. – SoftMemes Oct 23 '10 at 22:03

6 Answers6

1

If the class is only responsible for loading/saving TestPlan objects, and it has no other similar methods to load/save objects of other classes, it could be

class TestPlanXmlMarshaller {
    public TestPlan load(InputStream xmlFile) {
        ...
    }

    public OutputStream save(TestPlan testPlan) {
        ...
    }
}

This way, in accordance with the DRY principle, TestPlan and XML are not repeated unnecessarily in the method names.

However, if the class is dealing with multiple types, the load methods need to have distinct names since a method can't be overloaded on the return type only. save would be fine to overload with different type parameters, but for consistency the same naming convention should be used for both.

Péter Török
  • 114,404
  • 31
  • 268
  • 329
1

That looks very much like a serializer to me, so TestPlanSerializer or TestPlanXmlSerializer if you want to be specific.

SoftMemes
  • 5,602
  • 4
  • 32
  • 61
0

TestPlanXMLStreamer

Kdeveloper
  • 13,679
  • 11
  • 41
  • 49
0

Personally I don't believe in artifically shortening names of my classes, so you may find this suggestion to be to long.

TestPlanToXMLFileProcessor

I considered Writer instead of Processor but would want to avoid potential confusion with the likes of FileWriter etc.

Ideally your class would be more generic and could used for some Objects other than a TestPlan Object, then you could reuse it in other projects, but we all know thats not always possible or even sensible.

Kevin D
  • 3,564
  • 1
  • 21
  • 38
0

How about TestPlan2XmlConverter?

I would also recommend a slight change in design: Your two methods could read from and write to XML strings; this would make them a little more generic and flexible. And then you could have two more corresponding methods:

  • one to read an XML file into an XML string and then call parseTestPlanXml on that string
  • the other to call writeTestPlanXml and then write the resulting XML string to an XML file
knightofmathematics
  • 1
  • 1
  • How would using strings make them more flexible? Streams can write to IO objects _or_ in memory representations - strings are always in memeory. I would suggest using Reader and Writer rather than streams however, if the format is known to be text based. – SoftMemes Oct 23 '10 at 22:06
  • @Freed: Um, perhaps I got a little carried away by the way I would normally do it in C++. Thanks for pointing out the capabilities of streams. :-) – knightofmathematics Oct 23 '10 at 22:33
0

Two classes: TestPlanXMLReader and TestPlanXMLWriter

WW.
  • 23,793
  • 13
  • 94
  • 121