Dlaczego nie pola abstrakcyjne?

Dlaczego klasy Java nie mogą mieć pól abstrakcyjnych, tak jak mogą mieć metody abstrakcyjne?

Na przykład: Mam dwie klasy, które rozszerzają tę samą abstrakcyjną klasę bazową. Każda z tych dwóch klas ma metodę, która jest identyczna, z wyjątkiem stałej String, która jest komunikatem o błędzie. Gdyby pola mogły być abstrakcyjne, mógłbym uczynić tę stałą abstrakcją i przeciągnąć metodę do klasy bazowej. Zamiast tego muszę utworzyć metodę abstrakcyjną, wywoływaną getErrMsg()w tym przypadku, która zwraca String, przesłania tę metodę w dwóch klasach pochodnych, a następnie mogę wywołać metodę (która teraz wywołuje metodę abstrakcyjną).

Dlaczego nie mogłem po prostu zrobić abstrakcji na początku? Czy Java mogła na to pozwolić?

Możesz zrobić to, co opisałeś, mając końcowe pole w swojej klasie abstrakcyjnej, które jest inicjowane w jego konstruktorze (nieprzetestowany kod):

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

Jeśli twoja klasa potomna „zapomni” o zainicjowaniu finału przez superkonstruktor, kompilator wyświetli ostrzeżenie o błędzie, tak jak wtedy, gdy metoda abstrakcyjna nie jest zaimplementowana.

Nie widzę w tym sensu. Możesz przenieść funkcję do klasy abstrakcyjnej i po prostu przesłonić niektóre chronione pola. Nie wiem, czy to działa ze stałymi, ale efekt jest taki sam:

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

Chodzi ci więc o to, że chcesz wymusić implementację / nadpisanie / cokolwiek errorMsgw podklasach? Myślałem, że chciałeś mieć metodę w klasie bazowej i nie wiedziałeś wtedy, jak sobie radzić z polem.

Oczywiście można było to zaprojektować, aby na to pozwolić, ale pod osłonami nadal musiałby wykonywać dynamiczne wysyłanie, a zatem wywołanie metody. Projekt Javy (przynajmniej na początku) był do pewnego stopnia próbą bycia minimalistą. Oznacza to, że projektanci starali się unikać dodawania nowych funkcji, jeśli można je łatwo symulować za pomocą innych funkcji już w języku.

Czytając swój tytuł, pomyślałem, że odnosisz się do abstrakcyjnych członków instancji; i nie widziałem dla nich pożytku. Ale abstrakcyjne statyczne elementy to zupełnie inna sprawa.

Często marzyłem, żebym mógł zadeklarować metodę podobną do poniższej w Javie:

public abstract class MyClass {

    public static abstract MyClass createInstance();

    // more stuff...

}

Zasadniczo chciałbym nalegać, aby konkretne implementacje mojej klasy nadrzędnej zapewniały statyczną metodę fabryki z określonym podpisem. Pozwoliłoby mi to uzyskać odniesienie do konkretnej klasy Class.forName()i mieć pewność, że mogę ją skonstruować w wybranej przeze mnie konwencji.

Inną opcją jest zdefiniowanie pola jako publicznego (jeśli chcesz, jeśli wolisz) w klasie bazowej, a następnie zainicjowanie tego pola w konstruktorze klasy bazowej, w zależności od aktualnie używanej podklasy. Jest to trochę podejrzane, ponieważ wprowadza zależność cykliczną. Ale przynajmniej nie jest to zależność, która może się zmienić - tj. Podklasa będzie istnieć lub nie będzie istnieć, ale metody lub pola podklasy nie mogą wpływać na wartość 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;
    }
  }
}