Constructor vs method vs factory

Question

Imagine you want to export certain Document into File (in some format... let's say XML).

For this purpose I have class XmlExporter and the question is... what is the best approach to passing both Document and File to this class?

Option 1: Exporter is stateless, so if I want to export different document or into different file I just change the parameter. Disadvantage is that I have to pass the file (or rather OutputStream) in every single method (which in case of complex document can be quite a lot)

class XmlExporter { public function export(Document document, File file) { this.writeHeader(document.header, file); this.writeSomeOtherStuff(document.somethingElse, file); // and more ... } private function writeHeader(DocumentHeader header, File file) { writeName(header.name, file); // passing file over and over again } }

Option 2: Both source and target is stored within the instance. If I wanted to change the file I would have to create a new object, but now I don't need to worry about passing all necessary data.

class XmlExporter { private final Document document; private final File file; public XmlExporter(Document document, File file) { this.document = document; this.file = file; } public function export() { this.writeHeader(this.document.header); } private function writeHeader(DocumentHeader header) { this.writeName(header.name); } private function writeName(String name) { // ... } }

Option 3: Combination of both

class DocumentExporter { public static function exportToXml(Document document, File file) { XmlExporter exporter = new XmlExporter(document, file); exporter.export(); } // the rest same as Option 2, probably with private constructor }

Basically the second choice makes most sense for me from the perspective of writing the class, since I don't need to pass the target file/stream around; however from the point of actually using it I feel that the first choice would make more sense. What if I wanted to export it into standard output instead of file, or export multiple documents?

I would personally go with the second one because to me it basically is similar to how files are currently handled using the decorator pattern, but I wouldn't submit this as an answer. To me it seems that the choice between these 3 is largely a matter of what is appropriate at the time — Dan
– Dan, Commented May 24, 2014 at 16:23
What about using a fluent notation, new XmlExporter().document(d).file(f).export(); If you want to write to multiple files, the file() method might rely on a collection. — TeTeT
– TeTeT, Commented May 24, 2014 at 16:32

user3636971 · Accepted Answer · 2014-05-24 17:14:53Z

First of all, I would choose Option 2 to support the extension of the export process later (storing status, progress, etc. in the instance). You can add public properties for the File and the Document if you want them to be changable.

What if I wanted to export it into standard output instead of file, or export multiple documents?

Try to decouple the functionalities of your XmlExporter class. XmlExporter should be a Director, which responsibility is to parse the Document and notify a Handler (interface) attached at runtime - one Handler implementaion can write data to File, another to the Console.

Check out the Builder Design Pattern: http://www.blackwasp.co.uk/Builder.aspx

yegor256 · Accepted Answer · 2014-05-25 14:05:21Z

0

None. Exporter (as well as "manager", "controller", or any other "-er" ended names) are indicators of incorrect design. Instead, your Document should know how to export itself to a File:

document.exportTo(file);

answered May 25, 2014 at 14:05

yegor256

106k131 gold badges466 silver badges632 bronze badges

5 Comments

Honza Zidek Over a year ago

This is too strong an opinion I think. I personally do not like if a Document knows how to export itself to a File. This would be a bad design.

Honza Zidek Over a year ago

It's like if you wanted a Box being able to load itself to a Truck. The Document would have the compile-time dependency on the File, which creates unwanted tight coupling.

Carlo V. Dango Over a year ago

This is a typical OOP perspective. In enterprise systems, however, we rather often shy away from those principles and instead separates concerns in separate classes and layers.

yegor256 Over a year ago

In poorly designed enterprise systems :(

Honza Zidek Over a year ago

No, adding extra responsibility of exporting itself to a document is an attribute of a poor design. Both in OOP design as well as in enterpise systems.

Collectives™ on Stack Overflow

Constructor vs method vs factory

2 Answers 2

Comments

5 Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

Comments

5 Comments

Related