hi,ich hätte mal eine designfrage, ich habe zwei klassen:
RouterSettings
ProgramSettings
so in jeder dieser Klasse befinden sich lediglich Instanzvariablen(lauter Strings), diese beiden Klassen haben nicht miteinander zu tun, so nun meine frage ich möchte beide klassen serialisieren können, ist ja noch kein Problem!
Jetzt habe ich eine dritte Klasse namens ConfigFile, diese Klasse enthält zwei methoden readConfigFile und WriteConfigFile, die für beide Klassen exakt das gleiche macht, so nun meine Frage, soll ich readConfigFile und WriteConfigFile überlagern, so das eine Methode ein RouterSettings Object entgegennimmt und eine Methode ein ProgramSettings Object oder wie würde man das lösen???
Ich habe es bis jetzt so gemacht ich habe ein Interface erstellt namens ISettings, das komplett leer ist,also keine Methodenrümpfe und keine Propertys und beide Klassen erben von ISettings und dann habe ich nur eine Methode in der ConfigFile Klasse die so aussieht:
public void WriteConfigFile(ISettings data){
.........
}
kann man das so machen oder ist das eher nicht so toll??
lg rizi
Hallo rizi,
ein leeres Interface ist schon ein bisschen merkwürdig. Anderseits ist es sicher nicht sinnvoll, die Methode WriteConfigFile zweimal zu schreiben, vor allem wenn man sich vorstellt, dass später möglicherweise weiter Arten von *Settings-Klassen hinzukommen.
herbivore
ja,genau das ist ja mein dillemer herbie, es wäre ja auch möglich, dass man writeConfigFile und readConfigFile ein Object übergibt, aber ist das elegant?? hat jemand einen tipp für mich!!
lg rizi
Hallo,
wies ieht es denn aus. Ist die Methode WriteConfigFile für die beiden gleich. Oder sind diese komplett unterschiedlich. Wenn diese sich stark unterscheiden, spricht doch viel dafür diese Methoden jeweils in den Klassen RouterSettings und ProgrammSettings mitaufzunehmen. Vielliecht ist es noch geschickt ein Interface IConfigurable zu machen, dass die zwei Methoden beinhaltet und von Deinen Setting klassen implementiert wird.
Die Lösung mit dem leeren Interface vertstehe ich übrigens nicht.
Tschüss
hi,ja die beiden methoden readConfigFile und writeConfigFile sind für beide Klassen absolut(100%) identsch.
Ich wollte keine methode implementieren die ein Object übergeben bekommt und dashabl habe ich mich für eine interface entschieden, ja wie gesagt wäre für ratschläge dankbar,wie man so etwas realisiert!!!
Lg rizi
Hallo rizi,
naja, ein Dilemma scheint mir das nicht zu sein. Von den zwei Lösungen ist eine (identische Methode duplizieren) schlechter als die andere (leeres Interface). Ich würde dir auch zustimmen, dass Object als Parametertyp schlechter ist als ISettings. Also gibt es einen klaren Gewinner, selbst wenn auch diese Lösung selbst ihre Ecken und Kanten hat.
herbivore
so, was mir jetzt gerade eingefallen ist: gibt es eine möglichkeit, dass man ein Interface erstellt, dass eine Klasse zwing serialisierbar zu sein?? ich meine damit,dass wenn eine klasse dieses interface implementiert auch serialisierbar sein muss??
deshalb weil ja meine objekte serislisiert werden solln???
gibt es so eine möglichkeit, muss jetzt nicht unbedingt mit interfaces sein oder gibt es so etwas nicht?
lg rizi
Hallo rizi,
in die Richtung hatte ich auch erst überlegt. Aber mal abgesehen davon, dass es zwar ISerializable gibt, aber das nicht implementiert wird, wenn [Serializable] benutzt wird, ist die Serialisierbarkeit zwar Voraussetzung, aber nicht das entscheidende Kriterium. Das entscheidende Kriterium ist ja nun schon, dass es eine Settings-Klasse ist. Insofern ist dein Interface besser als ISerializable o.ä.
herbivore
Original von rizi
Ich habe es bis jetzt so gemacht ich habe ein Interface erstellt namens ISettings, das komplett leer ist,also keine Methodenrümpfe und keine Propertys und beide Klassen erben von ISettings und dann habe ich nur eine Methode in der ConfigFile Klasse die so aussieht:public void WriteConfigFile(ISettings data){ ......... }
kann man das so machen oder ist das eher nicht so toll??
hallo,
was ich nicht ganz verstehe ist warum du das Interface leer lässt, da die beiden von dir genannten Klassen mit der selben WriteConfigFile-Methode verarbeitet werden können/sollen, heisst das ja implizit, dass auch die Daten dieser Klassen auf dieselbe Weise abgerufen werden. Wäre es da nicht sinnvoll diese in beiden Klassen vorhandenen Elemente in deinem Interface aufzunehmen? Eine möglicherweise Dritte oder Vierte Klasse müsste diese ja auch bereitstellen um über die WriteConfigFile-Methode verarbeitet werden zu können.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Hallo Yellow,
er serialisiert die *Settings-Objekte in WriteConfigFile doch einfach. Sie müssen also nur als [Serializable] gekennzeichnet sein, aber keine bestimmten Methoden oder Properties anbietet. Und dass ein Typ als [Serializable] gekennzeichnet sein muss, kann man eben leider nicht in dem Interface ausdrücken. Deshalb ist es leer.
herbivore
stimmt, jetzt hat es klick gemacht.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de