Dlaczego nie abstrakcyjne pola?

Question

Dlaczego klasy Java nie mogą zawierać abstrakcyjnych pól, ponieważ mogą zawierać abstrakcyjne metody?

Na przykład: Mam dwie klasy, które rozszerzają tę samą abstrakcyjną klasę podstawową. Każda z tych dwóch klas ma metodę, która jest identyczna, z wyjątkiem stałej String, która w tym przypadku jest komunikatem o błędzie. Jeśli pola mogłyby być abstrakcyjne, mógłbym uczynić to stałym abstraktem i przenieść metodę do klasy bazowej. Zamiast tego, muszę utworzyć abstrakcyjną metodę o nazwie getErrMsg() w tym przypadku, która zwraca String, nadpisuje tę metodę w dwóch klasach pochodnych, a następnie mogę wywołać metodę (która teraz nazywa metodę abstrakcyjną).

Dlaczego nie mogę po prostu zrobić tego streszczenia na początek? Czy Java mogła zostać zaprojektowana, aby to umożliwić?

Answer 1

Można zrobić to, co opisane poprzez końcową boiska w swojej abstrakcyjnej klasy, która zostaje zainicjowany w jego konstruktora (kod niesprawdzone):

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 klasa dziecko „zapomina”, aby zainicjować ostateczna poprzez super konstruktor kompilator da ostrzeżenie błąd, tak jak wtedy, gdy metoda abstrakcyjna nie jest zaimplementowana.

Answer 2

Oczywiście można było może na to pozwolić, ale pod pokrywami nadal musiałaby odbywać się dynamiczna wysyłka, a więc wywołanie metody. Konstrukcja Javy (przynajmniej na początku) była w pewnym stopniu próbą minimalistyczną. Oznacza to, że projektanci starali się unikać dodawania nowych funkcji, jeśli mogliby być łatwo symulowani przez inne funkcje już w tym języku.

Answer 3

Nie widzę sensu w tym. Możesz przenieść funkcję do klasy abstrakcyjnej i po prostu zastąpić pewne chronione pole. Nie wiem, czy to działa ze stałymi ale efekt jest ten 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"; 
    } 
} 

Więc chodzi o to, że chcesz, aby wymusić wdrożenia/nadpisywanie/cokolwiek z errorMsg w podklasach? Myślałem, że po prostu chcesz mieć tę metodę w klasie bazowej i nie wiesz, jak sobie poradzić z tym polem.

Answer 4

Czytając tytuł, myślałem, że odnosisz się do abstrakcyjnych członków instancji; i nie widziałem dla nich większego pożytku. Ale abstrakcyjni statyczni członkowie to zupełnie inna sprawa.

mam często żałował, że mogę zadeklarować metodę jak poniżej w Javie:

public abstract class MyClass { 

    public static abstract MyClass createInstance(); 

    // more stuff... 

} 

Zasadniczo chciałbym twierdzą, że konkretne implementacje mojej klasy dominującej zapewniają metody statycznej fabryki z konkretnego podpisu . To pozwoliłoby mi uzyskać odniesienie do konkretnej klasy z Class.forName() i być pewnym, że mógłbym ją utworzyć w konwencji według mojego wyboru.

Answer 5

Inną opcją jest zdefiniowanie pola jako publicznego (końcowego, jeśli chcesz) w klasie bazowej, a następnie zainicjowanie tego pola w konstruktorze klasy bazowej, w zależności od tego, która podklasa jest aktualnie używana. Jest to trochę podejrzane, ponieważ wprowadza zależność cykliczną. Ale przynajmniej nie jest to zależność, która kiedykolwiek może się zmienić - tj. Podklasa będzie istnieć lub nie istnieje, 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; 
    } 
    } 
} 

Answer 6

Można zdefiniować sparametryzowany konstruktor w klasie abstrakcji.

ten sposób podklasy są zmuszeni do zdefiniowania własnych konstruktorów i nazwać super konstruktora, coś jak następuje:

public abstract class TransactionManager { 
    private String separator; 

    public TransactionManager(String separator) { 
     this.separator = separator; 
    } 
} 

Wtedy twój beton klasy wyglądałby następująco:

public class TransactionManagerFS extends TransactionManager{ 

    // The IDE forces you to implement constructor. 
    public TransactionManagerFS(String separator) { 
     super(separator); 
    } 
} 

sprawdzenia pełnej przykład z here.