Почему не абстрактные поля?

Почему классы Java не могут иметь абстрактные поля, как у них могут быть абстрактные методы?

Например: у меня есть два класса, которые расширяют один и тот же абстрактный базовый класс. Каждый из этих двух классов имеет идентичный метод, за исключением константы String, которая является сообщением об ошибке внутри них. Если бы поля могли быть абстрактными, я мог бы сделать эту константу абстрактной и перенести метод в базовый класс. Вместо этого мне нужно создать абстрактный метод, вызываемый 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()и быть уверенным, что я смогу построить его в соответствии с выбранным мной соглашением.

Другой вариант - определить поле как общедоступное (окончательное, если хотите) в базовом классе, а затем инициализировать это поле в конструкторе базового класса, в зависимости от того, какой подкласс в настоящее время используется. Это немного сомнительно, поскольку вводит циклическую зависимость. Но, по крайней мере, это не зависимость, которая может когда-либо измениться - то есть подкласс будет существовать или не существовать, но методы или поля подкласса не могут влиять на значение 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;
    }
  }
}