Конструктор для интерфейса/абстрактного класса с использованием дженериков Java

Похоже, вы действительно ищете решение, как написать универсальный фабричный метод без множества блоков if/else и без написания одного блока в каждом классе. Таким образом, рассмотрите возможность использования отражения, как в следующем коде:

interface Interface {
}

class Foo implements Interface {
    Foo(int magicInt) { magicInt = magicInt + 1; /* do some fancy calculations */ }
}

class Bar implements Interface {
    Bar(int magicInt) { magicInt = magicInt + 2; /* do some fancy calculations */ }
}

class Factory<T extends Interface> {
    int magicInt = 0; 

    public T createNewObject(Class<T> typeToMake) {
        try {
            T t = createNewObjectWithReflection(typeToMake);
            return t;
        } catch (Exception e) {
            throw new RuntimeException("Construction failed!", e);
        }
    }

    private T createNewObjectWithReflection(Class<T> typeToMake) throws Exception {
        // find the constructor of type to make with a single int argument
        Constructor<T> magicIntConstructor = typeToMake.getDeclaredConstructor(Integer.TYPE);
        // call the constructor with the value of magicInt
        T t = magicIntConstructor.newInstance(magicInt);
        return t;
    }
}

/* Name of the class has to be "Main" only if the class is public. */
class Ideone
{
    public static void main (String[] args) throws java.lang.Exception
    {
        Factory<Foo> fooFactory = new Factory<Foo>();
        Foo foo = fooFactory.createNewObject(Foo.class);
        System.out.println(foo);

        Factory<Bar> barFactory = new Factory<Bar>();
        Bar bar = barFactory.createNewObject(Bar.class);
        System.out.println(bar);
    }
}

Вы можете запустить демонстрацию в IDEOne здесь.

Я действительно не вижу, чтобы ваша идея работала.

Я чувствую, что это нарушает концепцию шаблона Factory, который на самом деле направлен на наличие метода, ответственного за создание экземпляров одного класса см. ссылку.

Я бы лучше:

1. иметь один метод в вашем фабричном классе для каждого типа объекта, который вы хотите построить
2. и, возможно, вместо того, чтобы иметь определенное поведение в конструкторах, иметь один общий конструктор в родительском абстрактном классе и один абстрактный метод, который выполняет причудливые вычисления (но это действительно предпочтение стиля).

Что приведет к чему-то вроде строк:

abstract class AbstractSample {
    private int magicInt;

    public AbstractSample(int magicInt) {
        this.magicInt = magicInt;
    }

    protected int getMagicInt() {
        return magicInt;
    }

    public abstract int fancyComputation();

}

public class Foo extends AbstractSample {
    public Foo(int magicInt) {
        super(magicInt)
    }

    public int fancyComputation() {
        return getMagicInt() + 1;
    }
}

public class Bar extends AbstractSample {
    public Bar(int magicInt) {
        super(magicInt)
    }

    public int fancyComputation() {
        return getMagicInt() + 2;
    }
}

public class SampleFactory {
    private int magicInt = 0;

    public Foo createNewFoo() {
        return new Foo(magicInt);
    }

    public Bar createNewBar() {
        return new Bar(magicInt);
    }
}

Ответ на предыдущую версию вопроса может быть удален, если обновленный ответ удовлетворяет OP

Определенно странно иметь классы, которые расширяют Sample и реализуют SampleFactory...

Я бы предпочел что-то вроде:

class Sample { 
    protected Sample() { /* ... */ }
}

interface SampleFactory<T extends Sample> {
    T createSample(final int i);
}

class AccelerationSample extends Sample {
    public AccelerationSample(final int i) { /* do some fancy int calculations*/ }
}

class OrientationSample extends Sample {
    private OrientationSample (final int i) { /* do some fancy int calculations*/ }
}

abstract class SampleSource<T extends Sample> {
    int magicInt; 
    SampleFactory<T> sampleFactory;
    T getCurrentSample() {
       return sampleFactory.createSample(magicInt);
    }
}

class AccelerationSampleSource extends SampleSource<AccelerationSample> {
    SampleFactory<AccelerationSample> sampleFactory = new SampleFactory<> {
       public AccelerationSample createSample(final int i) {
          return new AccelerationSample(i);
       }
    }
}

class OrientationSampleSource extends SampleSource<OrientationSample> {
    SampleFactory<OrientationSample> sampleFactory = new SampleFactory<> {
       public OrientationSample createSample(final int i) {
          return new OrientationSample(i);
       }
    }
}

Еще чище было бы использовать именованные фабрики, такие как

public AccelerationSampleFactory implements SampleFactory<AccelerationSample> {
    public AccelerationSample createSample(final int i) {
        return new AccelerationSample(i);
    }
 }

Который вы могли бы затем использовать как

class AccelerationSampleSource extends SampleSource<AccelerationSample> {
    SampleFactory<AccelerationSample> sampleFactory = new AccelerationSampleFactory();
}   

Как вы заметили, ни одна из трех идей в вопросе не поддерживается (конструктор с определенной сигнатурой в интерфейсе, абстрактный класс, обеспечивающий определенный конструктор, или статический метод в интерфейсе или абстрактном классе)

Однако вы можете определить интерфейс (или абстрактный класс), который является фабрикой для нужного вам типа.

public interface AnInterface {
    int fancyComputation();
}
public interface IFooBarFactory<T extends AnInterface> {
    T create(int magicNumber);
}

IFooBarFactory имеет 2 конкретные реализации

public class BarFactory implements IFooBarFactory<Bar> {
    public Bar create(int magicNumber) {
        return new Bar(magicNumber);
    }
}
public class FooFactory implements IFooBarFactory<Foo> {
    public Foo create(int magicNumber) {
        return new Foo(magicNumber);
    }
}

Затем используйте шаблон стратегии (https://en.wikipedia.org/wiki/Strategy_pattern). чтобы получить правильный завод. Затем используйте эту фабрику с известным интерфейсом для производства вашего объекта с правильным значением (и любыми дополнительными значениями, которые требуются для производства объекта).

    FooBarFactory fooBarFactory = new FooBarFactory();
    IFooBarFactory<T> factory = fooBarFactory.createFactory(typeOfAnInterface);
    T impl = factory.create(magicNumber);

С конкретными реализациями

public class Bar implements AnInterface {
    private final int magicInt;
    public Bar(int magicInt) {
        this.magicInt = magicInt;
    }
    public int fancyComputation() {
        return magicInt + 2;
    }
}
public class Foo implements AnInterface {
    private final int magicInt;
    public Foo(int magicInt) {
        this.magicInt = magicInt;
    }
    public int fancyComputation() {
        return magicInt + 1;
    }
}

следующий код:

public static void main(String ... parameters) {
    test(Foo.class);
    test(Bar.class);
}
private static <T extends AnInterface> void test(Class<T> typeOfAnInterface) {
    T impl = createImplForAnInterface(typeOfAnInterface, 10);
    System.out.println(typeOfAnInterface.getName() + " produced " + impl.fancyComputation());
}
private static <T extends AnInterface> T createImplForAnInterface(Class<T> typeOfAnInterface, int magicNumber) {
    FooBarFactory fooBarFactory = new FooBarFactory();
    IFooBarFactory<T> factory = fooBarFactory.createFactory(typeOfAnInterface);
    T impl = factory.create(magicNumber);
    return impl;
}

отпечатки

Foo produced 11
Bar produced 12

Это дает ряд преимуществ по сравнению с решением с самоанализом или статическими фабриками. Вызывающему не нужно знать, как производить какие-либо объекты, а вызывающему не требуется знать или заботиться о том, является ли метод «правильным» методом для использования для получения правильного типа. Все вызывающие объекты просто вызывают один общедоступный/известный компонент, который возвращает "правильную" фабрику. Это делает ваши вызывающие объекты более чистыми, потому что они больше не тесно связаны с конкретными реализациями AnInterface для типов FooBar. Им нужно только беспокоиться о том, что «мне нужна реализация AnInterface, которая потребляет (или обрабатывает) этот тип». Я знаю, что это означает, что у вас есть два "фабричных" класса. Один для получения правильной фабрики, а другой фактически отвечает за создание конкретных типов Foo и Bar. Однако вы скрываете эту деталь реализации от вызывающих объектов с помощью дополнительного уровня абстракции (см. метод createImplForAnInterface).

Этот подход будет особенно полезен, если вы обычно используете какую-либо форму внедрения зависимостей. Моя рекомендация точно соответствует внедрению с помощью Guice (https://github.com/google/guice/wiki/AssistedInject) или аналогичная идея в Spring (Возможно ли и как сделать Assisted Injection в Spring?).

Это означает, что вам нужно иметь несколько фабричных классов (или правил привязки внедрения зависимостей для Guice), но каждый из этих классов небольшой, простой и простой в обслуживании. Затем вы пишете небольшой тест, который извлекает все классы, реализующие AnInterface, и проверяете, что ваш компонент, реализующий шаблон стратегии, охватывает все случаи (через отражение — я бы использовал класс Reflections в org.reflections:reflections). Это дает вам полезную абстракцию кода, которая упрощает использование этих объектов, уменьшая избыточный код, ослабляя тесную связь компонентов и не жертвуя полиморфизмом.