Hallo zusammen!
Ich stelle mir gerade die Frage, ob es Sinn macht von einer leeren Basisklasse (oder Interface) zu erben um eine gewisse Gruppe von Klassen zusammenzufassen.
Ein Beispiel:
Es sollen die Klassen Kunde, Bestellung und Artikel entstehen.
Dazu gibt es zunächst die Klasse DataObject:
abstract class DataObject
{
//Diese Klasse ist leer!
}
Davon werden dann die Klassen Kunde, Bestellung und Artikel abgeleitet:
class Kunde : DataObject
{
//Name, Straße usw.
}
Diese Klassen sollen dann in einer Methode verarbeitet werden:
void Update(DataObject da)
{
//...
}
Macht es also Sinn, für diesen Fall eine Klasse zur schreiben und davon dann zu erben auch wenn diese keinerlei Funktion hat. Dadurch hat man zumindest die Sicherheit (im Gegensatz zu "object"), dass eine "richtige" Klasse übergeben wird.
Darf man sowas machen und wenn nicht, wie sollte man das sonst lösen.
MfG
Alex
Ich sehe keinen Sinn darin.
Wenn ich keinerlei gemeinsame Eigenschaften (Basisklasse) oder gemeinsame Funktionalität (Interface) habe, wozu sollte ich dann eine Klasse bzw. Interface definieren?
Huhu,
ich würde da auch auf ein Interface zurückgreifen...
interface IDataObj
{
...
}
public class Kunde : IDataObj
{
...
}
public class Bestellung: IDataObj
{
...
}
public class Artikel : IDataObj
{
...
}
public Update( IDataObj obj )
{
}
gruß Sieben
Nur die Kogge schwimmt! 😁
Ich würde auch auf jeden Fall das Interface verwenden, um mir nicht die Möglichkeit zu verbauen, später eventuell von einer Basisklasse ableiten zu können, wo es keinen Umweg über ein Interface gibt.
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Weder eine leere Basisklasse, noch ein leeres Interface macht Sinn.
Ich gebe svenson und Borg recht. Warum willst du Klassen "zusammenfassen" wenn sie keinerlei Gemeinsamkeiten haben? Und wenn du bei deinen Funktionen die Parameter richtig typisierst, brauchst du dir auch keine Gedanken darüber zu machen, dass eine "richtige Klasse" übergeben wird.
Hallo zusammen,
ich denke es kann (muss aber nicht zwangsläufig) überall dort Sinn machen, wo Reflection zum Einsatz kommen muss, und unterschiedliche Verhaltensweisen je nach "Klassentyp" herangezogen werden müssen.
Ich denke hier an ein Beispiel, das dynamisch alle Assemblies eines Unterordners sammelt, und dort alle Klassen instanziiert, die z.B. das Interface "RunFromStart" implementiert haben.
Hier wird nur der Konstruktor benötigt, und keine "gemeinsame Funktionalität".
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
In so einer Situation erachte ich aber den Weg über Attribute als sinnvoller.
Ich schließe mich ebenfalls Svenson und Borg an. Im Falle von Reflection, in der eine Methode verwendet wird die alle Klassen zusammsammelt die von einem bestimmten Typ stammen, würde ich eher auf Attribute zurückgreifen.
Ob das jetzt mehr Sinn macht ist dahingestellt, aber Klassen, die an sich keine Beziehungen zu einander haben, von einer leeren Klasse abzuleiten, halte ich für unsinnig.
"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)
das Interface "RunFromStart" implementiert haben.
Hier wird nur der Konstruktor benötigt, und keine "gemeinsame Funktionalität".
Das ist doch aber eine gemeinsame Funktionalität.
Hallo Borg,
ja im gewissen Sinne ist das eine gemeinsame "Funktionalität" auch wenn keine gemeinsame "Funktion" vorhanden ist (Methode) 😉
Attribute sind hier allerdings in der Tat besser angebracht.
Also dann habe ich auch keine Argumente für leere Klassen/Interfaces mehr.
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”