Использование основанного на отражении статического вызова вместо интерфейсов

Хорошо, потому что API Reflection намного медленнее, чем вызов метода, как при использовании рефлексии, компилятор вообще не может оптимизировать, поскольку он не может иметь никакого реального представления о том, что вы делаете.

Имея интерфейс и несколько конкретных классов, которые его реализуют, мы можем иметь преимущество полиморфного поведения. Добавьте шаблон Factory в уравнение, и вы можете напрямую работать с вашими интерфейсами без необходимости знать, какой конкретный метод класса вы вызываете. Дополнительным преимуществом является то, что компилятор сможет оптимизировать ваш код, заставляя его работать намного быстрее по сравнению с использованием Reflection API.

Начиная с Java 8, мы можем иметь статические и реализации методов экземпляра в интерфейсах. Вот демо:

public class InterfaceDemo
{
  public static void main(String... args)
  {
    XYZ.executeStatic("Hello");

    XYZ object = new Implementer();
    object.executeInstance("Message");
  }
}

interface XYZ
{
  static void executeStatic(String message)
  {
    System.out.println("Static: " + message);
  }

  default void executeInstance(String message)
  {
    System.out.println("Instance: " + message);
  }
}

class Implementer implements XYZ {}

Тогда есть функциональные интерфейсы, такие как:

@FunctionalInterface
public interface Returnable<T>
{
  public T value();
}

Это позволяет создавать различные реализации с использованием лямбда-выражений, таких как:

Returnable<Integer> integerReturnable = () -> 42;
Returnable<String> stringReturnable = () -> "Hello";

И используйте как:

System.out.println(integerReturnable.value()); // Prints 42
System.out.println(stringReturnable.value()); // Prints Hello

Кстати, если есть много объектов, которые нужно создать, мы используем шаблон пула объектов или что-то подобное, и если есть много похожих объектов, мы используем шаблон Flyweight, чтобы минимизировать использование памяти, сохраняя при этом скорость.