Array von (noch nicht bekannten bzw wechselnden) Klassen

  • C#
  • .NET (FX) 4.0

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von EaranMaleasi.

    Array von (noch nicht bekannten bzw wechselnden) Klassen

    Guten Abend,
    ich habe ein kleines Problem.
    Ich möchte gerne ein Array von Klassen machen. es gibt verschiedene. Aber alle haben die selben Variabeln, selben Funktionen...
    Wie kann ich solch ein Array erstellen/Funktionen/Variabeln ansprechen? Ist das überhaupt möglich?

    Ich habe es bereits mit einem Array von Objekten versucht und gegoogelt, jedoch habe ich nichts passendes dazu gefunden :(

    vielen Dank schonmal
    Lg Marcel

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcel1997“ ()

    Interfaces.
    Mit interfaces erstellst du einen "Vertrag" der aussagt, über welche Funktionen eine Klasse zwingend verfügen muss.
    Wenn du nun eine List<Vertrag> machst, kannst du jede Klasse, die diesem "Vertrag" implementiert hat, dort adden.
    hierbei kannst du properties und Methoden festlegen.

    C#-Quellcode

    1. interface iMyInterface
    2. {
    3. int blargh { get; set; }
    4. string DoStuff(string t);
    5. }

    C#-Quellcode

    1. class MyClass : iMyInterface
    2. {
    3. public int blargh
    4. {
    5. get;
    6. set;
    7. }
    8. public string DoStuff(string t)
    9. {
    10. return t;
    11. }
    12. }

    C#-Quellcode

    1. private void Form1_Load(object sender, EventArgs e)
    2. {
    3. List<iMyInterface> lsti = new List<iMyInterface>();
    4. MyClass mc = new MyClass();
    5. lsti.Add(mc);
    6. iMyInterface if1 = lsti[0];
    7. if1.blargh = 5;
    8. textBox1.Text = if1.DoStuff(if1.blargh.ToString());
    9. }

    Muss man sehen, ob Basisklasse oder Interface besser geeignet ist, generell geht ja beides.
    Wenn man sich nicht sicher ist und noch wenig Erfahrung mit Polymorphie hat würde ich generell erstmal zur Basisklasse raten, Interfaces eröffnen gleich ein noch größeres Spektrum der Komplexität (und natürlich der Möglichkeiten, aber sind diese nicht gefordert braucht mans auch nicht damit übertreiben).

    Ich glaube er mein Vererbungen.

    Beispiel. Du hast mehrere Streams, FilleStream, NetworkStream, MemoryStream und (zum schluss ne fiktive eigene inplementierte klasse^^) kinox.to Stream. Du willst du alle in ein Array packen. Dann nimmst du einfach ein Array von Typ Stream weil das die Basis klasse ist.

    @Erfinder des Rades:
    Klar macht das was er schreibt sin in beispiel auf Vererbungen, außer er meint die selbe klasse in der Solution merfach zu Deklarieren (naja gleiches Schema, sonst meckert eh der Complierer^^) dann hast du recht.

    @Marcel1997 Man verwendet keine Variablen in Klassen, diese sollten eigentlich immer Private oder Protected sein. Nach außen hin verwenden man Eigenschaften.

    EDIT @ErfinderDesRades: Als ich mir eine 5 Minuten Terrine machen wollte und ich den post zufällig offen hatte habe ich noch den Gedancken bekommen dass er nicht wircklich mehrere klassen sondern mehrere instanzen von genau einer klasse meint. Dann währen die Vererbungen ja schon mal aus den Spiel :D

    LG, Herbrich

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „zn-gong“ ()

    @EaranMaleasi danke für deine ausführliche Erklärung ! :) Werde ich heute nachmittag mal ausprobieren aber das sieht gut zu verstehen aus.
    @ErfinderDesRades @zn-gong
    Ich habe vor das jede dieser "verschiedenen" Klassen zwar gleich aufgebaut sind, aber die einzelnen Funktionen anders arbeiten.
    @zn-gong Ja, so mache ich das auch eigentlich :D aber was ist der große Unterschied?

    Danke @all :)

    Marcel1997 schrieb:

    Unterschied
    zwschen wem bzw. was?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Marcel1997 schrieb:

    Ich habe vor das jede dieser "verschiedenen" Klassen zwar gleich aufgebaut sind, aber die einzelnen Funktionen anders arbeiten.
    Dann mach mit abstrakter Basisklasse, nicht mit Interface.
    zn-Gongs Beispiel mit den Streams ist da ganz ausgezeichnet, denn das Stream-Konzept ist genau nach diesem System aufgebaut.
    Guck dir im ObjectBrowser die Klassen Stream (abstrakt) und FileStream, NetworkStream, MemoryStream, BufferedStream, CryptoStream etc. an.

    Über den OB kannst du hier einiges erfahren: VisualStudio richtig nutzen (Google ist nicht deine Mami) und mehr.

    Edit:

    Marcel1997 schrieb:

    Wieso sollte man Eigenschaften unf keine Variabeln verwenden? Wo liegt da der Vor-/Nachteil?
    Hör jetzt mal auf zu quatschen und fang an.
    Weitere Fragen kann man besser klären, wenn deine Beispiel vorliegen.


    @RodFromGermany & @Marcel1997
    Zwischen Variablen(Felder) und Properties.
    Der feine unterschied ist folgender:

    C#-Quellcode

    1. public class MoreStuff
    2. {
    3. public string stuff; // Variable / Field
    4. public string OtherStuff { get; set; } //Eigenschaft / Property
    5. }

    Felder sollte man nicht public machen, da man von außen sonst jederzeit in irgendeiner weiße da rumpfuschen kann.
    Bei Properties hingegen kann man Festlegen ob es lediglich gesetzt werden kann, ob es nur gelesen werden kann, oder ob, beim Setzen, oder holen des Wertes, etwas passieren soll:

    C#-Quellcode

    1. public string DerivedKey
    2. {
    3. get
    4. {
    5. return DerivedKey;
    6. }
    7. set
    8. {
    9. if(value.Length == 5)
    10. {
    11. DerivedKey = value;
    12. }
    13. }
    14. }

    Wenn man jedoch so etwas vorhaben sollte, sollte man darüber nachdenken die Properties mit privaten Feldern zu versehen:

    C#-Quellcode

    1. private string derivedKey;
    2. public string DerivedKey
    3. {
    4. get
    5. {
    6. return derivedKey;
    7. }
    8. set
    9. {
    10. if(value.Length == 5)
    11. {
    12. derivedKey= value;
    13. }
    14. else
    15. {
    16. derivedKey="to short";
    17. }
    18. }
    19. }

    Ich verwendet für dieses konzept auch Abstracte Basis klassen, da man so z.B. einfach "Gemeinsame Functionen" (d.h. alles was in allen klassen gleich sein soll) in der Basis klasse Inplementieren kann.

    Aber mal ne kleine Frage am rand: sind Interfaces nicht auch einsetzbar??

    LG, Herbrich

    Ich meine wen man nur "sicherstellen" will das bestimmte Sub,s, eigenschaften und functionen da sind. Diese aber nicht direkt inplementieren will dann reicht doch ein interface aus, in einer Basis klasse stehen in einigen elementen ja bereits eventuell codezeilen drinnen.

    LG, Herbrich

    Jou, wie aber die meisten hier schon eher richtig gesehen haben, möchte der TE eher eine Basisklasse haben, die eine gewisse Funktionalität bereitstellt, sodass er nur davon erben lassen muss, anstatt diese Funktion jedes mal erneut zu implementieren. Zudem kann man Funktionen ja noch overriden, was einem eine ganz ähnliche Möglichkeit wie Interfaces bietet.

    Gutes Beispiel für den Interface einsatz wäre ein DB-Connector-Wrapper, der die verschiedenen Connectoren (z.B. Oracle u. MySql) unter einem Hut vereint. So muss man seinen Quellcode nicht für jeden Connector völlig neu schreiben(etwas aufwand bleibt), sondern hat nur noch eine einzige Klasse, der die unterliegende DB so gut wie egal ist. Man verliert dadurch jedoch den Zugriff auf die Eigenarten der Connectoren, sofern man sich da nicht etwas Ausgefuchstes einfallen lässt. Die Connectoren müssen halt dann die Interfaces IDbConnection usw. Implementieren.

Facebook