Need opinion on correctness of strategy pattern usage

[Suvojit Chakraborty]

Hi,

I am beginning to apply patterns in my work. I have to make a functionality for export data in pdf and csv format. I am planning to use strategy pattern here. Following is in my mind.
I will have an interface IExportable with a ab method export()

interface IExportable {

public void export() ;

}

and two implementing classes :

class PDFExporter implements IExportable {

public void export () { 
// logic to export data in pdf
}
}

and

class CSVExporter implements IExportable {

public void export () { 
// logic to export data in csv
}
}

A factory will give me instance of appropriate Exporter. A ExportUtil will contain IExportable ref and a generateExport() to do export :

public class ExportUtil {

IExportable exporter;

public static generateExport ( String exportToken ) {

exporter  = ExporterFactory.getExporter(exportToken);

exporter.export();

}

Am I correct to pick Strategy pattern here? Is my design okay? Can it be improved?

Thanks for help

[Junilu Lacar]

The organization seems fine to me. I have a few issues with the names you used though.

Minor: IExportable - I prefer NOT using "I" to designate an interface. You don't see this convention in the standard Java API. This convention is a carry over from styles used in other languages which I don't particularly agree with. Not a big deal if your coding conventions dictate that you use "I" to designate interfaces. I would point out that it doesn't give me any useful information that I couldn't find out with a good IDE.

Major: Semantics of being "Exportable" doesn't fit the use. If an object is "Exportable" I would expect it to be the thing that is converted to PDF or CSV, not the thing that performs the conversion. That is, I would expect a Graph to be Exportable or a Table to be Exportable. What you have now is saying "You can export a PDFExporter" and "You can export a CSVExporter" which is not true. The PDFExporter can export something to PDF and the CSVExporter can export something to CSV.

It would make more sense to name the interface as Exporter. This would fit common conventions that qualify the interface name with something that indicates what the implementation specifically does. The name Exporter can easily be determined to be the interface while PdfExporter and CsvExporter (or alternatively, PdfExporterImpl and CsvExporterImpl) are specific implementations.

You still might want to keep the Exportable interface to define a common method that an Exporter implementation would use to get the data it needs to export.

public interface Exportable {
    Row next();
    boolean hasNext();
}

public class Table implements Exportable {
    ...

    @Override
    public Row next() { ... }

    @Override
    public boolean hasNext() { ... }
}

public interface Exporter {
    void export(Exportable source, File target) throws ExportException;
    void export(Exportable source, String target) throws ExportException;

    // other overloaded versions of exportTo 
    ...
}

public class PdfExporter implements Exporter {
    @Override
    public void export(Exportable source, File target) throws ExportException {
       ...
    }

    ...
}

public class CsvExporter implements Exporter {
    @Override
    public void export(Exportable source, File target) throws ExportException {
       ...
    }

    ...
}

[Tushar Goel]

You are saying right, Junilu, we have to use exporter to export something to either pdf, csv or others not to export the exporter. And this something is exportable.