¿Por qué no campos abstractos?

¿Por qué las clases de Java no pueden tener campos abstractos como pueden tener métodos abstractos?

Por ejemplo: tengo dos clases que extienden la misma clase base abstracta. Cada una de estas dos clases tiene un método que es idéntico excepto por una constante String, que resulta ser un mensaje de error, dentro de ellas. Si los campos pudieran ser abstractos, podría hacer este resumen constante y llevar el método a la clase base. En su lugar, tengo que crear un método abstracto, llamado getErrMsg()en este caso, que devuelve el String, anular este método en las dos clases derivadas, y luego puedo abrir el método (que ahora llama al método abstracto).

¿Por qué no podía hacer que el campo fuera abstracto para empezar? ¿Podría haber sido diseñado Java para permitir esto?

Puede hacer lo que describió al tener un campo final en su clase abstracta que se inicializa en su constructor (código no probado):

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";
    }
}

Si su clase hija "olvida" inicializar la final a través del superconstructor, el compilador dará una advertencia y un error, como cuando no se implementa un método abstracto.

No veo ningún sentido en eso. Puede mover la función a la clase abstracta y simplemente anular algún campo protegido. No sé si esto funciona con constantes pero el efecto es el mismo:

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";
    }
}

Entonces, ¿su punto es que desea hacer cumplir la implementación / anulación / lo que sea errorMsgen las subclases? Pensé que solo querías tener el método en la clase base y no sabías cómo lidiar con el campo entonces.

Obviamente, podría haber sido diseñado para permitir esto, pero bajo las sábanas todavía tendría que hacer un envío dinámico y, por lo tanto, una llamada a un método. El diseño de Java (al menos en los primeros días) fue, hasta cierto punto, un intento de ser minimalista. Es decir, los diseñadores intentaron evitar agregar nuevas funciones si podían simularse fácilmente con otras funciones que ya estaban en el lenguaje.

Al leer su título, pensé que se refería a miembros de instancia abstractos; y no pude verles de mucha utilidad. Pero los miembros estáticos abstractos es otro asunto completamente diferente.

A menudo he deseado poder declarar un método como el siguiente en Java:

public abstract class MyClass {

    public static abstract MyClass createInstance();

    // more stuff...

}

Básicamente, me gustaría insistir en que las implementaciones concretas de mi clase principal proporcionan un método de fábrica estático con una firma específica. Esto me permitiría obtener una referencia a una clase concreta Class.forName()y estar seguro de que podría construir una en una convención de mi elección.

Otra opción es definir el campo como público (final, si lo desea) en la clase base, y luego inicializar ese campo en el constructor de la clase base, dependiendo de la subclase que se esté utilizando actualmente. Es un poco turbio, ya que introduce una dependencia circular. Pero, al menos, no es una dependencia que pueda cambiar, es decir, la subclase existirá o no existirá, pero los métodos o campos de la subclase no pueden influir en el valor de 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;
    }
  }
}