| Die letzten 10 Beiträge |
| InformaTiger |
Ok, ich werde dann sehen welcher Lösungsweg am geeignetsten ist und diesen wählen.
Danke.
Mfg
InformaTiger |
| eulerscheZahl |
Ist auch eine Möglichkeit. Es gibt auch nicht immer den idealen Weg, sondern verschiedene, gleichwertige. |
| 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 |
| 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 
Gruss,
ED |
| InformaTiger |
Ja, na dann wird mir wohl nichts anderes übrig bleiben als eine "nutzlose" Klasse zu schreiben 
Danke,
Mfg
informaTiger |
| 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. |
| 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. |
| 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. |
| 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.
InformaTiger hat dieses Bild (verkleinerte Version) angehängt:
|
| 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; }
} |
|
|
| Es sind weitere Beiträge zu diesem Thema vorhanden. Klicken Sie hier, um sich alle Beiträge anzusehen. |
