Fragen zur Vererbung

[platonderweise]

Hallo ich habe ein paar kleine Fragen.
Ich möchte gerne den Namen der Subclasse in der Hauptklasse wiedergeben.
Bzw. Ich habe zwei Subklassen und eine Methode in der Hauptklasse soll in abhängigkeit der Subklassen
eine Berechnung durchführen. In der Methode Ausgabe funktionert das bei mir einfach mit

String s = " Flugzeugart :" + getClass() + "\n";

wobei das schon ungünstig ist da ich die Bezeichnung "Class" vorneweg nicht möchte.
Wenn ich jedoch versuche zu schreiben

String k = getClass()

dann klappt das leider nicht

 

[Gast2]

getClass() liefert dir ein Class Objekt. Auf dem kannst du nen paar Methoden aufrufen um den Klassenamen auszulesen.
Class (Java 2 Platform SE 5.0)

Was genau ist denn deine Frage?!

 

[triopsfreak]

Im oberen Code wird automatisch gecastet, weil da ja nur String geht.
Im unteren musst du noch einen Cast machen, also (String) vor getClass() hinschreiben. Oder du machst getClass().toString(), das liefert einen String, der das Objekt repräsentiert, ist von Objekt zu Objekt verschieden. Du könntest sogar noch eine dritte Variante machen, mit String.valueOf(getClass()), bin mir aber gerade nicht sicher, ob das funktioniert, sollte aber eigentlich schon....

 

[platonderweise]

hat jetzt bei mir mit

getClass().getName()

funktioniert.
Ist das legitim?

 

[Gast2]

Warum sollte das nicht legitim sein?

 

[...ButAlive]

Ich habe zwei Subklassen und eine Methode in der Hauptklasse soll in abhängigkeit der Subklassen eine Berechnung durchführen.

Was du machen willst:

public class A
{
	public String doSomething(){
		Class<? extends A> clazz = this.getClass();
		
                if(clazz == A.class)
                        return "Das ist die Basis";

		if(clazz == B.class)
			return "HALLO";
		
		if(clazz == C.class)
			return "WELT";
		
		else		
			return "Unbekannte Klasse";
	}
}

public class B extends A{}

public class C extends A{}

Und der Test

public static void main(String[] args)
{
	B b = new B();
	C c = new C();
		
	System.out.println(b.doSomething());
	System.out.println(c.doSomething());
}

Aber was ist, wenn du eine Klasse D einfügen willst? Du musst A anfassen und ändern. Es wäre also besser wenn A gar nicht seine Subklassen kennt.

Die selbe Ausgabe bekommt man auch folgendermaßen hin:

public class A
{
	public String doSomething()
	{
		return "Das ist die Basis";
	}
}

public class B extends A
{
	@Override
	public String doSomething()
	{
		return "HALLO";
	}
}

public class C extends A
{
	@Override
	public String doSomething()
	{
		return "WELT";
	}
}

In deinem Fall bedeutet das, dass du die Algorithmen für die einzelnen Subklassen aus der Basisklasse in die Subklassen verlagern musst.

 

[HoaX]

Im oberen Code wird automatisch gecastet, weil da ja nur String geht.
Im unteren musst du noch einen Cast machen, also (String) vor getClass() hinschreiben. ...

Das mit dem Cast stimmt nicht! Da fliegt dir eine ClassCastException, bzw. es meckert in diesem Fall hier sogar schon der Kompiler.

 

[Gast2]

Im oberen Code wird automatisch gecastet, weil da ja nur String geht.

Da wird die toString() Methode des Class Objekts aufgerufen.

 

[TheWhiteShadow]

Bzw. Ich habe zwei Subklassen und eine Methode in der Hauptklasse soll in abhängigkeit der Subklassen
eine Berechnung durchführen.

Da ist ein Anfänger-Denkfehler drinn.

Wenn die Aktion von der Subklasse abhängt, muss sie dort implementiert werden.
Die Elternklasse darf gar nicht wissen, wo sie extendend wird.

Damit du sie über die Basis-Klasse aufrufen kannst deklarierst du sie dort leer oder besser als abstract.
Die Kind-Klassen müssen dann diese Methode üerschreiben.

Vorteil: Für jede Kindklasse ist das Verhalten bekannt und expliziet angegeben.

 

[Landei]

Die Kunst ist, das Gemeinsame der Berechnung wenn möglich in die Elternklasse zu packen, und die Besonderheiten in die Unterklassen. Ein einfaches Beispiel:

public abstract class Edelmetall {
   private double preis;
   public Artikel(double preis) {
      this.preis = preis;
   }

   public abstract double mwst();

   public double endPreis() {
      return preis + preis*mwst()/100.0;  //allgemeine Berechnungsvorschrift
   }
}

public class Platin extends Edelmetall {
   public Platin(double preis) {
      super(preis);
   }
   public double mwst() { return 19.0; } //spezieller Teil der Berechnung
}

public class Gold extends Edelmetall {
   public Gold(double preis) {
      super(preis);
   }
   public double mwst() { return 0.0; } //spezieller Teil der Berechnung
}

public class Silber extends Edelmetall {
   public final boolean muenze;
   public Silber(double preis, boolean muenze) {
      super(preis);
      this.muenze = muenze;
   }
   public double mwst() { 
      return muenze ? 7.0 : 19.0; //spezieller Teil der Berechnung
   }
}

(Das entspricht übrigens der tatsächlichen Regelung in Deutschland)

Wenn du versucht bist, Fallunterscheidungen anhand des Typs anzustellen, machst du es in 99% der Fälle falsch: die Typhierarchie ist verunglückt, du hast bestimmte Beziehungen nicht berücksichtigt u.s.w.

Zu den wenigen Ausnahmen zählt der Umgang mit externen Daten, über die man keine Compilezeit-Informationen verfügt (etwa wenn man einen Objekt-Browser für eine IDE schreiben will) oder im Zusammenhang mit Generics (wenn durch "Type Erasure" Informationen verloren gehen), also eher bei fortgeschrittenen Themen.

 

[platonderweise]

Vielen Dank ihr habt mir in diesem Fall wirklich sehr weit geholfen.
Eine offene Frage hätte ich noch.
Laut Aufgabenblatt soll ich die Variablen in der Mutterklasse als private deklarieren.
Diese Muss ich dann aber im Konstruktor einer Subklasse implementieren.
Ich hab gedacht ich kann keine als private deklarierte variable des Mutterklasse in der Subklasse verändern.
Oder gibt es da Möglichkeiten/Ausnahmen

 

[.k3]

Vielen Dank ihr habt mir in diesem Fall wirklich sehr weit geholfen.
Eine offene Frage hätte ich noch.
Laut Aufgabenblatt soll ich die Variablen in der Mutterklasse als private deklarieren.
Diese Muss ich dann aber im Konstruktor einer Subklasse implementieren.
Ich hab gedacht ich kann keine als private deklarierte variable des Mutterklasse in der Subklasse verändern.
Oder gibt es da Möglichkeiten/Ausnahmen

Wenn ich das richtig verstanden habe, kannst du dieses Problem über Set/Get-Methoden lösen.
Also in der Mutterklasse public Methoden die den Wert der Variablen zurückgeben, bzw. diesen in der Mutterklasse verändern.

 

[Landei]

Eine offene Frage hätte ich noch.
Laut Aufgabenblatt soll ich die Variablen in der Mutterklasse als private deklarieren.
Diese Muss ich dann aber im Konstruktor einer Subklasse implementieren.
Ich hab gedacht ich kann keine als private deklarierte variable des Mutterklasse in der Subklasse verändern.
Oder gibt es da Möglichkeiten/Ausnahmen

Normalerweise sieht das so aus:

public class Mutterklasse {
   private int geheim;
   public Mutterklasse(int nichtgeheim) {
       this.geheim = nichtgeheim;
   }
}

public class Subklasse {
   public Subklass(int nichtgeheim) {
       super(nichtgeheim);
   }
}

Wie du siehst, wird die private Membervariable im Konstruktor der Mutterklasse gesetzt (was ja erlaubt ist), aber zu dessen Initialisierung der "von außen" (z.B. von der Subklasse) übergebene Wert verwendet.

Was für einen Anfänger ziemlich verwirrend sein kann, ist das Zusammenspiel der verschienedenen Namensräume: Man könnte in obigen Beispiel durchaus die Variable "nichtgeheim" überall in "geheim" umbenennen, und es würde trotzdem funktionieren, weil es immer noch zwei unterschiedliche Variablen sind, die nur zufällig gleich heißen. Im Konstruktor der Mutterklasse würde sich dann der Name "geheim" auf das übergebene Argument beziehen, und "this.geheim" auf die Membervariable. Der Fachbegriff für diese Namensüberdeckung ist Shadowing ("Überschattung").

Java hat übrigens vier getrennte Namensräume, und zwar für Typen (z.B. Klassen), Variablen, Methoden und Packages, die untereinander nicht zu Namenskonflikten führen. Es ist zwar extrem schlechter Stil, aber absolut valider Java-Code, folgendes zu schreiben:

package foo;

class foo {
   foo foo;
   foo(foo foo){
      this.foo = foo;
   }
   foo foo() {
      return foo;
   }
}

Jetzt fehlen nur noch Generics (ich glaube, die gehören zum Typ-Namensraum, aber 100% sicher bin ich da nicht)...