2
\$\begingroup\$

I am currently attempting to understand the fundamentals of factory methods in Java and I found a lot of exampels where a pattern like this has been used.
I got some exercises about sorting algorithms where one task is to write a factory class for all existing algorithms but with the requirement that newly added algorithmes can be integrated via "plug and play". That phrase itched me.By using the switch case solution I would be unable to add Algorithms without rewriting the factory class so I came up with this:

SorterFactory.java

public final class SorterFactory
{

  private SorterFactory()
  {
  }

  public static Sortierer.Sorter getNewSorter( Sorts sorts )
  {
    try
    {
      return (Sortierer.Sorter) Class.forName( sorts.getName() ).getConstructor().newInstance();
    }
    catch ( ClassNotFoundException | InstantiationException | IllegalAccessException
        | IllegalArgumentException | InvocationTargetException | NoSuchMethodException
        | SecurityException e )
    {
      e.printStackTrace();
      // further exception handling
    }
  }
}

Sorts.java

public final class Sorts
{

  private String name;

  // hardcoded for test purpose.
  // will be imported from XML-file
  public static final Sorts HEAPSORT = new Sorts( HeapSort.class.getName() );
  public static final Sorts MERGESORT = new Sorts( MergeSort.class.getName() );
  public static final Sorts BUBBLESORT = new Sorts( BubbleSort.class.getName() );
  public static final Sorts INSERTSORT = new Sorts( InsertSort.class.getName() );
  public static final Sorts QUICKSORT = new Sorts( QuickSort.class.getName() );
  public static final Sorts TRUEHEAPSORT = new Sorts( TrueHeapSort.class.getName() );

  private Sorts( String name )
  {
    this.name = name;
  }

  public String getName()
  {
    return name;
  }
}

So why is the switch case approach much more favored above this kind of solution in terms of safety,security and performance? Also is it useful to box the names in a class to prevent the misusage of the factory method instead of allow Strings as arguments?

Thanks for any advice and criticism.

\$\endgroup\$

closed as off-topic by t3chb0t, Imus, Stephen Rauch, Sᴀᴍ Onᴇᴌᴀ, Dannnno Apr 6 '18 at 13:30

This question appears to be off-topic. The users who voted to close gave these specific reasons:

  • "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Stephen Rauch, Sᴀᴍ Onᴇᴌᴀ, Dannnno
  • "Code not implemented or not working as intended: Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, performance, and scalability. We require that the code be working correctly, to the best of the author's knowledge, before proceeding with a review." – t3chb0t, Imus
If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Welcome to Code Review! Unfortunately your question is off-topic as of now, as the code to be reviewed must be present in the question. Please add the code you want reviewed in your question. Thanks! \$\endgroup\$ – Dannnno Apr 6 '18 at 13:29
1
\$\begingroup\$

In general reflection is slow (relative), makes code harder to understand and near impossible to debug if things go wrong.

So if you already know the exact class it's far better to let the compiler check against typo's for you at compile time.

A second issue is that the way it's written now, you just shifted the problem of "rewriting the factory class" to "rewriting the Sorts class". You can't add any other public constant to that class based on an XML file.


This isn't entirely clear from the limited problem statement you've given, but perhaps you've misunderstood what kind of factory they expect.

Another interpretation of the factory method pattern expects you to provide a factory interface. This interface defines one or more methods that create some Sorter. That way you can "plug" in any other factory to use a different Sorter. (Which, compared to just plugging in a different Sorter directly, is only useful if certain Sorters require something extra to create them. For example an extra input parameter.)

Note that this is still usually defined at compile time.

\$\endgroup\$
  • \$\begingroup\$ Thank you alot, that is excatly the type of feedback I needed. And you are right, I would have to rewrite/recompile the Sorts class in my current implementation. That's why I am currently working on a more dynamic solution. \$\endgroup\$ – L.Spillner Apr 6 '18 at 11:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.