Vererben von Superklasse ohne Konstruktor

mapadu

Mitglied
Hallo Leute 🙂

also ich hab das Forum durchstöbert und leider auf die schnelle nicht die Antwort auf meine spezifische Frage gefunden :

Ich muss von einer Klasse erben, die aber keinen Konstruktor definiert hat.

Java:
public class Grafikobjekt {

	private String beschriftung = "";
	private String grafik = "";

	private double drehung = 0;
	private double x = 0;
	private double y = 0;

	/**
	 * @return die Beschriftung des Grafikobjekts
	 */
	public String getBeschriftung() {
		return beschriftung;
	}

(...)usw.

die Datenfelder brauche ich aber, da diese unbedingt in der Subklasse sein müssen, da ich von der aus noch an zwei Andere vererben muss(bei denen Die Datenfelder entsprechen initialisiert werden müssen). Wie verhalte ich mich da? Ich habs gegoogelt aber da kommen leider immer nur erklärungen zur Vererbung wo Konstruktoren vorhanden sind...

Hierarchie der Vererbung:

(1)Grafikobjekt(Stück code oben):
(2)Lauftier:
2 a)Ameise
2 b) Fresstier


Liebe Grüße !
 
Ich muss von einer Klasse erben, die aber keinen Konstruktor definiert hat.
Eine Klasse, wo man den Konstruktor im Code nicht sieht, hat trotzdem einen. Das ist dann der sog. Defaultkonstruktor (ein Parameterloser Konstruktor, der alle Instanzvariablen mit den in der Java-Spec definierten Defaultwerten oder den bei Deklaration selbst gewählten Werten belegt). Aber das war sicher nicht Dein Problem. Wenn Grafikobjekt die Superklasse ist und die Datenfelder dort durch die Subklassen definierbar sein sollen, musst Du Dir eben den entsprechenden Konstruktor bauen. Ansonsten wären auch Getter und Setter nicht schlecht.
 
Java ist eine OOP und muss nunmal für jede Klasse einen Konstruktor erstellen. Irgdenwie muss ja ein Objekt entstehen 😉

Super ist das Stichwort. Um also zu vererben:

Java:
super.getName();
super.getX();

public String getName() {
  return super.getName();
}

grüße Spin
 
Java ist eine OOP und muss nunmal für jede Klasse einen Konstruktor erstellen. Irgdenwie muss ja ein Objekt entstehen 😉

Super ist das Stichwort. Um also zu vererben:

Java:
super.getName();
super.getX();

public String getName() {
  return super.getName();
}

grüße Spin



Das ist nicht nötig. Es sei denn, du möchtest proteced auf public heben.

Beispiel:

Java:
package forumProblems.getterFromSuperclass;

public class Eins {

    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

}

Java:
package forumProblems.getterFromSuperclass;

public class Zwei extends Eins {

    public static void main(String[] args) {
        Zwei zwei = new Zwei();
        System.out.println("Zwei hat den Namen " + zwei.getName());
    }

    public Zwei() {
        setName("Zwei");
    }

}

Ausgabe:
Code:
Zwei hat den Namen Zwei
 
Wer gibt das vor?

Warum können die Properties nicht nach
Code:
Lauftier
verschoben werden?

bye
TT

Hey ho, schau dir mal die Properties an und dann denke ich wirst du der gleichen Meinung sein wie ich, dass


Java:
private String beschriftung = "";
    private String grafik = "";
 
    private double drehung = 0;
    private double x = 0;
    private double y = 0;

doch nicht nach Lauftier gepackt werden müssen.
An der Stelle ist eine abstrakte klasse grafikobjekt ganz sinnvoll, oder eher ein interface. Ein Trait wäre noch schöner aber gibts net in Java. Jedes Lauftier soll diese Properties bekommen und sobald es später ein Nicht Lauftier geben soll dann war der Umstieg der Properties zu Lauftier nicht sinnvoll.

Schön wäre doch die Abstrakte klasse klein zu halten und eventuell während der Laufzeit zu erweitern 🙂 (Bridge :toll🙂
 
Hat sie doch, aber keinen expliziten 😉

Interfaces haben keinen Konstruktor, aber Klassen schon 😛. Ich schätze der TO soll die Vererbung lernen und später aus der Klasse ein Interface machen. Also bisher sind dort doch nur properties - warum also ein Konstruktor. Sobald ein Konstruktor verwendet wird ist man ja so inflexible 😉

Ach ja abstrakte Klassen haben auch gewöhnlich kein Konstruktor - und ne Instanz von einer Abstrakten klasse bilden geht net 😉

Wobei bei abstrakten Klassen, die als Schablone fungieren - doch der Konstruktor von der Subklasse festgelegt werden kann.
 
Also bisher sind dort doch nur properties - warum also ein Konstruktor. Sobald ein Konstruktor verwendet wird ist man ja so inflexible 😉
:lol:

Ach ja abstrakte Klassen haben auch gewöhnlich kein Konstruktor:
Falsch
- und ne Instanz von einer Abstrakten klasse bilden geht net 😉
Daraus kann man doch aber nicht schließen, dass sie keinen Konstruktor braucht...

Wobei bei abstrakten Klassen, die als Schablone fungieren - doch der Konstruktor von der Subklasse festgelegt werden kann.
Du meinst, sie können einen der angebotenen nutzen?
Ja.

bye
TT
 

Zurück
Oben