Абстрактный конструктор класса param против абстрактного метода для окончательных данных - PullRequest
0 голосов
/ 01 мая 2020

Каковы плюсы / минусы использования конструктора абстрактного класса по сравнению с абстрактным методом для передачи окончательных данных в абстрактный класс?

Передача через конструктор:

public abstract class MyAbstractClass<T> {
  private final String type;
  private final Function<String, T> factoryFn;

  protected MyAbstractClass(String type, Function<String, T> factoryFn) {
    this.type = type;
    this.factoryFn = factoryFn;
  }

  public T doSomething(String value) { ... }
}

Передача с помощью абстрактного метода:

public abstract class MyAbstractClass<T> {
  abstract String getType();

  abstract T getFactoryFn(String value);

  public T doSomething(String value) { ... }
}

Я знаю, что абстрактные методы потенциально могут быть использованы неправильно, поскольку не всегда необходимо возвращать одно и то же значение.

Но кроме этого, это просто вопрос личных предпочтений, или есть ли реальные (не) преимущества в использовании одного над другим?

1 Ответ

1 голос
/ 01 мая 2020

Надеюсь, я правильно понимаю ваш вопрос ..

Обычно, когда свойство класса всегда содержится в поле, более лаконично использовать абстрактный конструктор. Например, рассмотрим два следующих сценария ios ....

// Scenario 1:
abstract class AClass {
    final int field;
    public AClass(int f) {
        field = f;
    }

    public int getField() {
        return field;
    }
}

class Class1 extends AClass {
    public Class1(int f) {
        super(f);
    }

    // Class Unique Code...
}

class Class2 extends AClass {
    public Class2(int f) {
        super(f);
    }

    // Class Unique Code...
}


// Scenario 2:
abstract class AClass {
    public abstract int getField();
}

class Class1 extends AClass {
    final int field;

    public Class1(int f) {
        field = f;
    }


    @Override
    public int getField() {
        return field;
    }

    // Class Unique Code...
}


class Class2 extends AClass {
    final int field;

    public Class2(int f) {
        field = f;
    }


    @Override
    public int getField() {
        return field;
    }

    // Class Unique Code...
}

Сценарий 1 короче, так как логика получения c для field указывается только один раз. Принимая во внимание, что в сценарии 2 логика получения c должна быть переопределена обоими подклассами. Я считаю сценарий 2 избыточным ... зачем писать один и тот же код дважды, если вы можете использовать наследование java в своих интересах.

В заключение, я обычно не держу функции в полях, если в этом нет полной необходимости. Всякий раз, когда у вас есть функция в поле, обычно это признак того, что абстрактная функция может быть применена.

Вот ваш оригинальный код с моим советом ...

public abstract class MyAbstractClass<T> {
    private final String type;

    protected MyAbstractClass(String t) {
        type = t;
    }

    protected abstract T applyFactoryFunction(String value);

    public T doSomething(String value) { ... }
}

Надеюсь, это помог!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...