Viele verschiedene Objekte vom selben Typ

  • VB.NET

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Viele verschiedene Objekte vom selben Typ

    Hi und an alle die es feiern, Frohe Ostern ^^

    Wollte mal nachfragen wie ihr das umsetzen würdet, wenn ihr von einem bestimmten Typ z. B. Klasse Auto mehrere Objekte erstellen müsst.
    Also es gibt eine Liste die alle Autos hält. Diese Autos werden zur Laufzeit erstellt und können in verschiedensten Varienten auftreten.

    Beispiele wären:

    Farbe: Blau
    Modell: Blubb
    PS: 190
    Max. km/h: 250
    Türen: 2
    Typ: XS
    Aktuelle km: 0
    ...

    Wenn man davon jetzt 10 erstellt später nochmal 10 und eben so weiter.
    Nur das es von diesen Bauplänen eben einige gibt, welche alle vom gleichen Typ sind und alle in eine Liste landen sollen.
    Wie macht man das richtig?

    Ich bin mir nicht ganz sicher ob ich dich richtig verstanden habe. Ich hätte folgende Vorschläge:

    1.) Für 10 verschiedene Autos 10 verschiedene Konstruktoren - z.B. indem man dem Konstruktor einen Enum Wert übergibt.
    Jeder Prototyp entspricht einem Enum.

    oder

    2.) Ne Liste mit deinen Prototypen erstellen und aus dieser Liste die Prototypen rauskopieren (über.clone())

    Willst du die Werte deiner Prototypen alle in den Code hardcoden oder von einer Datenbank, Textdatei oder serialiserten Liste lesen?

    "Hardcoden".
    Und das mit der Enum Wert den man dem Konstruktor übergibt, war auch meine Idee nur finde ich sieht das ganze total unsauber aus.
    Also ich hatte es so, das dann durch einen Select Case (übergebener Enum Wert beim New aufruf) die richtigen Werte in das Objekt geschrieben werden, und so nur noch die Art des Typs dem Konstruktor übergeben werden muss.
    Nur ob das so die wahre Lösung ist, bin ich mir nicht sicher.

    Hi
    Das, was markus.obi vorschlägt sieht irgendwie nach Redundanz aus. Wie wäre folgendes? Du hast folgende Klassen:
    - Bauplan (Türen, Sitze, Equipment)
    - AutoProperties (Lack, etc.)
    - AutoModell
    - Auto
    - AutoInstanz (Position des Autos, Rotation oder so)
    und alles, was quasi mehrere Autos in ihrer Kategorie gleich haben, was aber nicht durch Vererbung ausgedrückt werden kann.
    Also: Bauplan ist die Zusammensetzung eines Autos (2 Türen, 3 Lenkräder, etc.), AutoProperties gibt dir die Eigenschaften (Blauer Fahrer, halt wirklich konkrete Werte) an, die eine spezifische Autogruppe (Auto) hat (bei denen alle Instanzen des konkreten Autos gleich sind, z.B. 5x Blubb in Blau). Das Automodell nimmt im Konstruktor einen Bauplan entgegen, das Auto dann das Automodell und due AutoProperties. Die kannst du ggf. auch auf dem Auto selber definieren, wenn die statisch sind. Bei allen AutoInstanz-Instanzen sind alle AutoProperties gleich und ich merk grad, dass ich nen wunderbaren Englisch-Deutsch wechsel drin hab.

    Gruß
    ~blaze~

    Z.b. so:

    VB.NET-Quellcode

    1. Public Class Layout
    2. Private ReadOnly _doors, _wheels As Integer
    4. Public Sub New(ByVal doors As Integer, ByVal wheels As Integer)
    5. _doors = doors
    6. _wheels = wheels
    7. End Sub
    9. Public ReadOnly Property Doors As Integer
    10. Get
    11. Return _doors
    12. End Get
    13. End Property
    15. Public ReadOnly Property Wheels As Integer
    16. Get
    17. Return _wheels
    18. End Get
    19. End Property
    20. End Class
    22. Public Class CarModel
    23. Private ReadOnly _layout As Layout
    25. Public Sub New(ByVal layout As Layout)
    26. _layout = layout
    27. End Sub
    29. Public ReadOnly Property Layout As Layout
    30. Get
    31. Return _layout
    32. End Get
    33. End Property
    34. End Class
    36. Public Class Car
    37. Private ReadOnly _model As CarModel
    38. Private ReadOnly _color As Color
    40. Public Sub New(ByVal auto As CarModel, ByVal color As Color)
    41. _model = auto
    42. _color = color
    43. End Sub
    45. Public ReadOnly Property Color As Color
    46. Get
    47. Return _color
    48. End Get
    49. End Property
    51. Public ReadOnly Property Model As CarModel
    52. Get
    53. Return _model
    54. End Get
    55. End Property
    56. End Class
    58. Public Class CarInstance
    59. Private ReadOnly _car As Car
    61. Public Sub New(ByVal car As Car)
    62. _car = car
    63. End Sub
    65. Public Property PositionX As Single
    66. Public Property PositionY As Single
    67. Public Property PositionZ As Single
    68. Public Property ResprayColor As Color
    69. Public Property Flags As CarInstanceFlags
    71. Public ReadOnly Property Car As Car
    72. Get
    73. Return _car
    74. End Get
    75. End Property
    77. Public ReadOnly Property CarColor As Color
    78. Get
    79. Return If((Flags And CarInstanceFlags.Resprayed) = CarInstanceFlags.Resprayed, ResprayColor, Car.Color)
    80. End Get
    81. End Property
    82. End Class
    84. <Flags()> _
    85. Public Enum CarInstanceFlags
    86. None = 0
    87. IsDriverDrunk = 1
    88. Resprayed = 2
    89. End Enum


    Gruß
    ~blaze~

    Aber würde das nicht darauf hinauslaufen, das ich einfach nur Instanzen erstelle und jede eingenschaft in den Konstruktoren mitgebe?
    Oder ging es um die Sache mit den Flags? Wobei da ja eig. nur das Select Case mit If Abfragen ersetzt wurde.

    Eistee schrieb:

    Aber würde das nicht darauf hinauslaufen, das ich einfach nur Instanzen erstelle und jede eingenschaft in den Konstruktoren mitgebe?

    das wäre das einfachste und gradlinigste.
    Macht auch nicht unbedingt sooo viel Mehrarbeit, denn ob du einen Satz Eigenschaften nun einmal festlegst, oder innerhalb einer Schleife 30 mal - annähernd egal.

    Eine Alternative wäre noch ein Copy-Konstruktor, der anhand eines im Konstruktor übergebenen Auto-"Prototypen" dem neuen Auto identische Eigenschaften verleiht.

    Noch annere Alternative, die ebenfalls einen Klon erzeugt wäre die Implementation der ICloneable-Schnittstelle.
    Letzteres könnte etwas Code einsparen, indem man Base.MemberwiseClone() verwendet, und nur die Properties setzt, die beim MemberwiseClone zu Fehlverhalten führen würden.
    Hierfür ist aber Kenntnis des Unterschiedes von Klasse und Struktur notwendig, sowie verlässliche Bestimmung von ReadOnly Membern.