Чому не абстрактні поля?

Чому класи Java не можуть мати абстрактні поля, як вони можуть мати абстрактні методи?

Наприклад: У мене є два класи, які розширюють один і той самий абстрактний базовий клас. Кожен із цих двох класів має ідентичний метод, за винятком рядкової константи, яка, як трапляється, є повідомленням про помилку. Якби поля могли бути абстрактними, я міг би зробити цю константу абстрактною і перетягнути метод в базовий клас. Натомість я маю створити абстрактний метод, викликаний getErrMsg()у цьому випадку, який повертає String, замінює цей метод у двох похідних класах, і тоді я можу витягнути метод (який тепер викликає абстрактний метод).

Чому я не міг просто зробити поле абстрактним для початку? Чи могла Java бути розроблена, щоб дозволити це?

Ви можете зробити те, що описали, маючи останнє поле у ​​своєму абстрактному класі, яке ініціалізується в його конструкторі (неперевірений код):

abstract class Base {

    final String errMsg;

    Base(String msg) {
        errMsg = msg;
    }

    abstract String doSomething();
}

class Sub extends Base {

    Sub() {
        super("Sub message");
    }

    String doSomething() {

        return errMsg + " from something";
    }
}

Якщо ваш дочірній клас "забуде" ініціалізувати фінал за допомогою суперконструктора, компілятор видасть попередження про помилку, як і тоді, коли абстрактний метод не реалізований.

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

public abstract class Abstract {
    protected String errorMsg = "";

    public String getErrMsg() {
        return this.errorMsg;
    }
}

public class Foo extends Abstract {
    public Foo() {
       this.errorMsg = "Foo";
    }

}

public class Bar extends Abstract {
    public Bar() {
       this.errorMsg = "Bar";
    }
}

Отже, ваша суть полягає в тому, що ви хочете застосувати імплементацію / перевизначення / що завгодно errorMsg підкласів? Я думав, ви просто хотіли мати метод у базовому класі і тоді не знали, як поводитися з полем.

Очевидно, що це могло бути розроблено, щоб дозволити це, але під обкладинками все одно довелося б робити динамічну диспетчерику, а отже, виклик методу. Дизайн Java (принаймні в перші дні) був певною мірою спробою бути мінімалістичним. Тобто дизайнери намагалися уникати додавання нових функцій, якщо їх можна було легко змоделювати іншими функціями, які вже є в мові.

Читаючи ваш заголовок, я думав, що ви маєте на увазі абстрактних членів екземпляра; і я не бачив для них особливої ​​користі. Але абстрактні статичні члени - це зовсім інша справа.

Я часто хотів, щоб я міг оголосити такий спосіб, як наведений нижче в Java:

public abstract class MyClass {

    public static abstract MyClass createInstance();

    // more stuff...

}

По суті, я хотів би наполягати на тому, що конкретні реалізації мого батьківського класу забезпечують статичний заводський метод із конкретним підписом. Це дозволило б мені отримати посилання на конкретний клас з Class.forName()і бути впевненим, що я можу побудувати його за умовою мого вибору.

Інший варіант полягає у визначенні поля як загальнодоступного (final, якщо хочете) у базовому класі, а потім ініціалізації цього поля в конструкторі базового класу, залежно від того, який підклас використовується зараз. Це трохи тіньово, оскільки вводить кругову залежність. Але, принаймні, це не залежність, яка коли-небудь може змінитися - тобто підклас буде або існувати, або не існувати, але методи або поля підкласу не можуть впливати на значення field.

public abstract class Base {
  public final int field;
  public Base() {
    if (this instanceof SubClassOne) {
      field = 1;
    } else if (this instanceof SubClassTwo) {
      field = 2;
    } else {
      // assertion, thrown exception, set to -1, whatever you want to do 
      // to trigger an error
      field = -1;
    }
  }
}