Klassen Wie kann ich auf untergordnetes Klassenattribut zugreifen?

[ubik]

Hallo,

angenommen ich hab zwei Klassen.

class Klasse1 {
public getMyString() {
return ???
}
}

class Klasse2 extends Klasse1 {
String mystring = "test";
}

Wie kann ich nun auf das Attribut mystring mit Klasse1 zugreifen?

 

[JStein52]

So rum gar nicht. Eine Superklasse kann ja nicht wissen was sie für Subklassen hat.

 

[ubik]

Gibt es eine Möglichkeit das Problem irgendwie anders zu lösen?

 

[InfectedBytes]

beschreib doch mal das eigentlich Problem. Was willst du im Endeffekt erreichen?

 

[JStein52]

Wenn du mit "Problem" das meinst was du als Frage formuliert hast ist die Antwort "Nein".

Edit: ich gehe mal davon aus dass du gerade irgendwelche Aufgaben durchgehst und bei dieser hier ein Verständnis für Vererbung entwickeln sollst.

 

[udo-100]

Warum willst du von der Klasse1 auf Klasse2 zugreifen?
Grundsätzlich greifen keine Klassen auf andere zu, sondern nur die Instanzen von Klassen.
Warum willst du ein Objekt der Klasse1 erstellen wenn das Objekt der Klasse2 alles von 1 erbt?
Klasse2 erbt doch alles von Klasse1 und hat somit auch das Attribut mystring.
Mit dem erben will man nur Code sparen.

 

[mrBrown]

Warum willst du von der Klasse1 auf Klasse2 zugreifen?
Grundsätzlich greifen keine Klassen auf andere zu, sondern nur die Instanzen von Klassen.
Warum willst du ein Objekt der Klasse1 erstellen wenn das Objekt der Klasse2 alles von 1 erbt?
Klasse2 erbt doch alles von Klasse1 und hat somit auch das Attribut mystring.
Mit dem erben will man nur Code sparen.

'mystring' gibt es in Klasse 1 nicht. Erben sollte man auf keinen Fall, um Code zu sparen.

 

[udo-100]

Auch ich lass mich gern belehren.

@mrBrown
Was ist dann der Sinn des Erbens wenn nicht die Code Einsparung (Wiederverwendbarkeit) ?

 

[JStein52]

wenn nicht die Code Einsparung (Wiederverwendbarkeit)

Ihr meint sicher beide Objektorientierung. Und da ist Wiederverwendbarkeit der eine wichtige Punkt und Kapselung ein anderer. Und vielleicht gibt es noch ein paar mehr

 

[udo-100]

Sorry wenn ich hier noch mal einhacke.
Ich meinte nicht die Objektorientierte Programmierung als ganzes, sondern nur die Vererbung von Klassen.
Und da sehe ich nur Code Einsparung als Sinn.

 

[JStein52]

Ok, hacke ruhig ich würde dir zustimmen. Aber vielleicht erklärt uns @mrBrown ja auch noch seine Sichtweise

 

[mrBrown]

Man sollte dann erben, wenn auch wirklich eine ist-Beziehung existiert, wenig Code sollte da mMn eher ein Nebenprodukt sein, an erster Stelle sollten Wiederverwendbarkeit und Wartbarkeit stehen.

 

[JStein52]

wenn auch wirklich eine ist-Beziehung existiert

Ich glaube das ist aber nicht das Primäre. Die ist-Beziehung ergibt sich ja erst dadurch das du Vererbung hast. Ohne Vererbung ist diese Sichtweise obsolet.

 

[udo-100]

ok, das lassen wir mal so stehen.

noch einen schönen Abend.

 

[JStein52]

an erster Stelle sollten Wiederverwendbarkeit und Wartbarkeit stehen

Und auch das wird ja ein Nebeneffekt der Codeeinsparung !

 

[Meniskusschaden]

Zu dem Thema passt vielleicht die Diskussion "Wiederverwendung durch Vererbung oder Komposition" wie sie z.B. hier kurz vorgestellt wird: http://www.fh-wedel.de/~si/seminare/ws97/Ausarbeitung/2.Winter/gamma12.htm

Die ist-Beziehung ergibt sich ja erst dadurch das du Vererbung hast.

Ich glaube, das ist der springende Punkt. Bei einem schlechten Entwurf schafft man in manchen Fällen künstlich eine "ist ein"-Beziehung, weil es intuitiv nahe liegt, obwohl es für den Fall vielleicht der fasche Weg ist. Vererbung ist zunächst bequem und verleitet zum übertriebenen Einsatz.

 

[mrBrown]

Ich glaube das ist aber nicht das Primäre. Die ist-Beziehung ergibt sich ja erst dadurch das du Vererbung hast. Ohne Vererbung ist diese Sichtweise obsolet.

Wenn man die Klassen nicht um ihrer selbst Willen schreibt, liegt ja irgendwie Konzept dahinter, welches die Beziehung vorgibt, und die sollte man dann auch abbilden

Und auch das wird ja ein Nebeneffekt der Codeeinsparung !

in den meisten Fällen ja Aber nur Code einsparen wollen führt nicht unbedingt zu besserem Code, und genauso führt besserer Code nicht zu eingesparten Code, ansonsten wäre LoC DAS Qualitätskriterium

 

[stg]

ansonsten wäre LoC DAS Qualitätskriterium

Das einzige Qualitätskritierum, was wirklich von Bedeutung ist, sind eh nur die WTF/min während des Code-Reviews.

 

[JStein52]

liegt ja irgendwie Konzept dahinter, welches die Beziehung vorgibt

Aber welches Konzept liegt denn dahinter wenn ich mir für Objekte vom Typ LKW, Sportwagen, Limousine, Bagger, Panzer überlege dass die ja Gemeinsamkeiten haben die ich in einer Klasse Fahrzeug zusammenfasse ? Das Konzept ist doch sich zu ersparen die Teile die gemeinsam sind in jeder Klasse wieder neu zu implementieren, also diese nur einmal an einer Stelle zu haben, also Codeersparnis. Und die Effekte die sich dadurch einstellen nennt man Wiederverwendbarkeit, Kapselung, verbesserte Wartbarkeit usw.

 

[JStein52]

Aber nur Code einsparen wollen führt nicht unbedingt zu besserem Code

Ja klar. Aber es geht ja nicht darum ein Problem mit möglichst wenig Code zu lösen sondern darum ein Problem nur einmal zu lösen und dadurch Code einzusparen !

 

[Dompteur]

Wie kann ich nun auf das Attribut mystring mit Klasse1 zugreifen?

Man kann in Java vieles tun. Manches sollte man aber besser lassen. So auch das hier.
Hier einmal ganz wertfrei, wie man auf die Instanzvariable zugreifen kann.

public class Klasse1 {
    public String getMyString() {
        return ( this instanceof Klasse2 ) ? ((Klasse2)this).mystring : "";
    }
}

Ich hoffe, dass es sich hier nur um eine Übung handelt.
So ein Konstrukt würde in der Praxis nämlich auf ein schweres Designproblem hinweisen.

 

[JStein52]

schweres Designproblem

Ja so geht es zwar technisch aber Klasse 1 kennt ja Klasse 2 nicht ! Sollte sie jedenfalls nicht. Und das ist das angesprochene Designproblem.

 

[ubik]

Hallo,

also es geht um folgende Klassen:

class Mitarbeiter {
int budget;
}
class Chef {
String naechsterTermin;
}
class ChefSekretaerin {
}


Nun sollen Chef und ChefSekretaerin auf die Variable "budget" schreiben können. Mitarbeiter sollen "budget" nur lesen können.

 

[InfectedBytes]

Um die gleiche Problematik geht es auch in deinem anderen Thread
http://www.java-forum.org/thema/kla...wert-zugreifen-koennen-klasse-3-nicht.172668/

 

[mrBrown]

Aber welches Konzept liegt denn dahinter wenn ich mir für Objekte vom Typ LKW, Sportwagen, Limousine, Bagger, Panzer überlege dass die ja Gemeinsamkeiten haben die ich in einer Klasse Fahrzeug zusammenfasse ? Das Konzept ist doch sich zu ersparen die Teile die gemeinsam sind in jeder Klasse wieder neu zu implementieren, also diese nur einmal an einer Stelle zu haben, also Codeersparnis. Und die Effekte die sich dadurch einstellen nennt man Wiederverwendbarkeit, Kapselung, verbesserte Wartbarkeit usw.

Naja, es sind alles Fahrzeuge, und das Konzept existiert auch vollkommen ohne Implementation.
Und weil es alles Fahrzeuge sind, ergibt sich uU die Codeersparnis. Man lässt sie ja nicht zu Fahrzeugen werden, weil man dadurch Code sparen kann.

Zu Vererbung gibt es dieses super Zitat von James Gosling: „Was würden Sie an Java ändern, wenn Sie es neu erfinden könnten?“ „Ich würde die Klassen weglassen.“
Erklärung davon ist der Missbrauch von Vererbung, um Code zu sparen

 

[ubik]

Um die gleiche Problematik geht es auch in deinem anderen Thread
http://www.java-forum.org/thema/kla...wert-zugreifen-koennen-klasse-3-nicht.172668/

Hallo,

es ist aber eine andere Aufgabe:

Mitarbeiter sollen Mitarbeiterbudgets lesen können, Änderungen hieran sol-
len aber nur Chefs oder Chefsekretärinnen gestattet werden. Begründen Sie,
warum Sie dies nicht mit einem Zugrismodizierer für das Attribut budget
erreichen können. Zeigen Sie stattdessen eine andere Lösung auf.

Die alte Aufgabe umfassende ja eine andere Problematik. Die habe ich so gelöst:

package firma.chefetage;

public class Chef {
   String naechsterTermin = "Test";
  
   public String getTermin() {
     return this.naechsterTermin;
   }
  
   void setTermin(String t) {
     this.naechsterTermin = t;
   }
  
   void setBudget(int b) {
    
   }
}

package firma.chefetage;

public class ChefSekretaerin extends Chef {

}

package firma.mitarbeiteretage;

import firma.chefetage.*;

public class Mitarbeiter extends Chef {
   int budget = 100;
  
   public int getBudget() {
     return this.budget;
   }
}

Dort war ja das Problem, dass naechsterTermin nur von Mitarbeiter gelesen werden kann und von Chef und Chefsekretaer geschrieben werden kann.

Hier haben wir das Problem, dass budget nur von Mitarbeitern gelesen werden kann und von Chef und Chefsekretaer geschrieben werden kann.

 

[InfectedBytes]

Dort war ja das Problem, dass naechsterTermin nur von Mitarbeiter gelesen werden kann und von Chef und Chefsekretaer geschrieben werden kann.

Hier haben wir das Problem, dass budget nur von Mitarbeitern gelesen werden kann und von Chef und Chefsekretaer geschrieben werden kann.

Der einzige Unterschied ist doch bloß, dass die Variablen anders heißen. Ansonsten ist es exakt das gleiche Problem

 

[mrBrown]

Der einzige Unterschied ist doch bloß, dass die Variablen anders heißen. Ansonsten ist es exakt das gleiche Problem

Der Mitarbeiter soll sein eigenes Budget nicht lesen können, so wie ich die Aufgabe verstehe. Bei den Terminen sollte jeder lesen, aber nicht jeder schreiben können.

u.U mit abstracter Klasse und verschiedenen packages lösen, vllt hab ichs aber auch falsch verstanden.

 

[Joose]

@ubik Code bitte in Code-Tags posten, danke!
[java] ... dein code .... [/java]

Ja die Aufgabenstellung ist eine etwas andere, aber ich sehe das große Problem: Wer sollte ein Objekt daran hindern sein eigenes Attribut zu ändern bzw. zu lesen?
Was darfst du am vorgegebenen Code alles an Änderungen vornehmen? Für mich ist die Aufgabe so nicht lösbar, erst wenn ich generell das Attribut in eine andere Klasse schieben kann oder ähnliches.

 

[JStein52]

Das Problem ist hier nicht ganz das gleiche wie beim Termin. Den Termin hatte ja nur der Chef und andere sollten ganz bestimmte Sachen damit machen können oder auch nicht. Hier hat jeder ein Budget und Mitarbeiter Chef und Chefsekretärin sollen bestimmte sachen machen können. Und die Frage ist ja nun wie kann man einen Mitarbeiter daran hindern sein eigenes Budget zu schreiben ?!

Da wir ja Vererbung nicht nur zur Codeersparnis einsetzen wollen könnte man eine gemeinsame Superklasse zu Mitarbeiter, Chef und Chefsekretärin einfügen die das Attribut Budget sowie getter und setter dafür enthält. Wenn man diese Superklasse in das gleiche package legt wie Chef und Chefsekretärin und die setter für das Budget package-private macht müsste es doch funktionieren.