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