Laden...

DesignFrage - logisch ähnliche objekte -- Interface?? oder nicht??

Erstellt von rizi vor 16 Jahren Letzter Beitrag vor 16 Jahren 2.439 Views
R
rizi Themenstarter:in
402 Beiträge seit 2005
vor 16 Jahren
DesignFrage - logisch ähnliche objekte -- Interface?? oder nicht??

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

49.485 Beiträge seit 2005
vor 16 Jahren

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

R
rizi Themenstarter:in
402 Beiträge seit 2005
vor 16 Jahren

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

A
254 Beiträge seit 2007
vor 16 Jahren

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

R
rizi Themenstarter:in
402 Beiträge seit 2005
vor 16 Jahren

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

49.485 Beiträge seit 2005
vor 16 Jahren

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

R
rizi Themenstarter:in
402 Beiträge seit 2005
vor 16 Jahren

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

49.485 Beiträge seit 2005
vor 16 Jahren

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

R
rizi Themenstarter:in
402 Beiträge seit 2005
vor 16 Jahren

o.k, danke für deine antworten!!

lg rizi

476 Beiträge seit 2004
vor 16 Jahren

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

49.485 Beiträge seit 2005
vor 16 Jahren

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

476 Beiträge seit 2004
vor 16 Jahren

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