Це можливо, але не так, як у вас.
Вам потрібно додати конструктор no-args до базового класу і все!
public abstract class A {
private String name;
public A(){
this.name = getName();
}
public abstract String getName();
public String toString(){
return "simple class name: " + this.getClass().getSimpleName() + " name:\"" + this.name + "\"";
}
}
class B extends A {
public String getName(){
return "my name is B";
}
public static void main( String [] args ) {
System.out.println( new C() );
}
}
class C extends A {
public String getName() {
return "Zee";
}
}
Коли ви не додаєте конструктор (будь-який) до класу, компілятор додає стандартний конструктор no arg для вас.
Коли defualt no arg викликає super (); і оскільки у вас його немає в суперкласі, ви отримуєте це повідомлення про помилку.
Ось про питання саме воно.
Тепер, розширюючи відповідь:
Чи знаєте ви, що створення підкласу (поведінки) для вказівки різних різних значень (даних) не має сенсу ?? !!! Я сподіваюся, що ви це зробите.
Якщо єдине, що змінюється, це "ім'я", то достатньо одного параметризованого класу!
Отже, вам це не потрібно:
MyClass a = new A("A");
MyClass b = new B("B");
MyClass c = new C("C");
MyClass d = new D("D");
або
MyClass a = new A();
MyClass b = new B();
MyClass c = new C();
MyClass d = new D();
Коли ви можете написати це:
MyClass a = new MyClass("A");
MyClass b = new MyClass("B");
MyClass c = new MyClass("C");
MyClass d = new MyClass("D");
Якби мені було змінити підпис методу конструктора BaseClass, мені довелося б змінити всі підкласи.
Ну ось чому успадкування - це артефакт, що створює ВИСОКЕ зчеплення, що небажано в системах ОО. Його слід уникати і, можливо, замінити композицією.
Подумайте, чи вони вам справді потрібні як підклас. Ось чому ви бачите дуже часто використовувані інтерфейси insted:
public interface NameAware {
public String getName();
}
class A implements NameAware ...
class B implements NameAware ...
class C ... etc.
Тут B і C могли успадкувати від A, який створив би дуже ВИСОКУ зв'язок між ними, за допомогою інтерфейсів зв'язок зменшився, якщо A вирішив, що вона більше не буде "NameAware", інші класи не зламаються.
Звичайно, якщо ви хочете повторно використовувати поведінку, це не спрацює.