Java Up- und Downcasting

Neue Frage »

Auf diesen Beitrag antworten »
InformaTiger Java Up- und Downcasting

Hallo,

ich habe folgendes Problem: ich habe zwei Klassen eine Klasse Configuration und eine Klasse RemoteConfiguration. Die zweite ist eine Unter- bzw. Kindklasse der ersten und hat zusätzliche Felder (Port, Hostname, Username, etc.). Ich möchte jetzt zwischen den beiden Klassen casten und zwar so, dass ich aus der Configuration eine RemoteConfiguration machen kann und umgekehrt.

Es ist erwünscht, dass beim Casten von RemoteConfiguration in Configuration (also der Elternklasse) die Daten der Kindklasse (Port, ...) verloren gehen. Nur habe ich nachgelesen, dass dies nicht geht bzw. auch keinen Sinn macht, da die RemoteConfiguration ja bereits eine Configuration ist.

Ich möchte verhindern eine weitere Klasse zu schreiben welche (fast) leer ist nur um zwischen Remote und Local (das wäre die Leere Klasse) umschalten zu können, da die Klasse Configuration bereits alles beiinhaltet was ich benötige.

Mit freundlichen Grüßen
informaTiger
 
Auf diesen Beitrag antworten »
eulerscheZahl

Und wenn du einfach eine Referenz auf die Elternklasse verwendest, also
code:
1:
Configuration c = remoteConfigurationInstance;

Aber die Polymorphie wird du so nicht los.
Ich weiß nicht, was du genau vorhast und ob der Cast wirklich nötig ist, aber du wirst das Objekt nicht mehr zur Elternklasse umbiegen können. Alternativ könntest du über eine Aggregation an Stelle einer Vererbung nachdenken.
code:
1:
2:
3:
4:
5:
class RemoteConfiguration {
    private Configuration c;

    public Configuration getConfiguration() { return c; }
}
Auf diesen Beitrag antworten »
InformaTiger

Ich möchte innerhalb meines Projektes in Lokaler Konfiguration und Fern Konfiguration unterscheiden. Sobald ein Benutzer auf den Radiobutton Lokal klickt, werden die Fern Konfigurationsdaten nicht mehr benötigt und deshalb das Objekt in eine Lokale Konfiguration umgewandelt.
Wechselt der User wieder zurück auf Fern Konfiguration soll das bestehende Objekt wieder erweitert werden und die Felder wie Port, Hostname, etc. erhalten.

Edit: Im Anhang der entsprechende Auschnitt aus dem UML Diagramm des Projektes.
Auf diesen Beitrag antworten »
eulerscheZahl

Soweit ich sehe, überschreibst du die Basisklasse nicht, oder? Dann würde tatsächlich mein erster Vorschlag genügen.
Ansonsten erben LocalConfiguration und RemoteConfiguration beide von Configuration.
 
Auf diesen Beitrag antworten »
InformaTiger

Wie meinst du das? Also RemoteConfiguration erbt von Configuration. Und LocalConfiguration würde das dann auch machen. Ich benötige nur für LocalConfiguration keine weiteren Felder, weswegen ich sie mir gerne gespart hätte.
Auf diesen Beitrag antworten »
eulerscheZahl

Du hast schon ganz richtig verstanden, was ich meine.

Manchmal geht es eben nicht so, wie man will. Ich hätte mich neulich sehr über Mehrfachvererbung gefreut, da muss man dann eben Kompromisse machen, wenn die Sprache das nicht hergibt.
Auf diesen Beitrag antworten »
InformaTiger

Ja, na dann wird mir wohl nichts anderes übrig bleiben als eine "nutzlose" Klasse zu schreiben großes Grinsen

Danke,

Mfg
informaTiger
Auf diesen Beitrag antworten »
ed209

Das klingt nicht so als wuerde es Dein Problem loesen.

Wenn Du von RemoteConfig nach Config castest hast Du noch immer ein Objekt der Klasse RemoteConfig. Lediglich deine Variable ist vom [I]Typ[/] Config. Wenn Du jetzt versuchst deine RemoteConfig-Objekt nach LocalConfig zu casten bekommst du einen Laufzeitfehler.

Das Objekt wird zu keinem Zeitpunkt veraendert.

Wenn Downcasts noetig sind, ist das meistens weil die Abstraktions-Level nicht sauber sind, und das ist eigentlich vermeidbar, solange das Framework das man verwendet einen nicht dazu zwingt.

Mal ganz simpel gefragt:

Was hindert Dich daran eine einzelne Klasse zu machen, die alle informationen enthaelt und ein weiteres Feld "boolean isRemoteConfig" falls noetig.
Und in dem Moment wo jemand auf lokal umstsellt, setzt Du alle Werte die Du nicht haben willst auf null

Wenn Du wirklich darauf bestehst zwei verschiedene Klassen zu haben, dann wuerde ich das mit Delegation und einem gemeinsamen Interface loesen. Aber den Aufwand wuerd ich nur rechtfertigen wenn die Abstraktion es wirklich erfordert Augenzwinkern

Gruss,
ED
Auf diesen Beitrag antworten »
InformaTiger

Sagen wir so: diesen ganzen Aufwand betreibe ich nur, damit es von der logischen Seite ausgesehen richtig strukturiert ist. Andererseits kann ich auch darauf verzichten RemoteConfiguration und LocalConfiguration in Verbindung zu setzen. In anderen Worten: ich schreibe mir eine Klasse welche für die Backup Konfiguration zuständig ist und eine zweite welche nur die Login Informationen fürs Remote Backup enthält. Die Sache mit isRemoteConfig oder nicht kann ich ganz einfach damit lösen, dass ich in der Klasse BackupConfiguration ein Objekt von RemoteLoginData (oder so ähnlich) erstelle und es mit null vergleiche.

Was hält ihr davon?

Mfg
InformaTiger
Auf diesen Beitrag antworten »
eulerscheZahl

Ist auch eine Möglichkeit. Es gibt auch nicht immer den idealen Weg, sondern verschiedene, gleichwertige.
Auf diesen Beitrag antworten »
InformaTiger

Ok, ich werde dann sehen welcher Lösungsweg am geeignetsten ist und diesen wählen.
Danke.

Mfg
InformaTiger
 
Neue Frage »
Antworten »


Verwandte Themen

Die Beliebtesten »
Die Größten »
Die Neuesten »