Objektmanagement mit konstanten Eigenschaften

  • Allgemein

Es gibt 19 Antworten in diesem Thema. Der letzte Beitrag () ist von Mangafreak1995.

    Objektmanagement mit konstanten Eigenschaften

    Hey Leute,

    ich habe gerade in Gedanken ein kleinen Konflikt.

    Ich habe eine Objektliste, wobei diese am Anfang einen konstanten Wert kriegen. Da einige doppelt sein werden bin ich am Überlegen über Ids und einer Wertetabelle zu arbeiten.
    Jetzt kann ich mir aber gut vorstellen, dass das zugreifen auf die Tabelle langsamer ist als wenn die Werte direkt in den Objekten sind, würde aber auf jeden Fall Speicher sparen.

    Welche Option sollte ich wählen und warum ? Wie sollte ich am besten die Tabelle optimal managen (also falls die Option in Frage kommt) ?

    Danke für eure Vorschläge.

    Mangafreak

    Definiere Wertetabelle.

    Wenn einige Einträge doppelt sind stellt sich die Frage, ob diese nicht entfernt werden können (.Distinct()).
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Die werden doppelt da sein müssen, da es Objekte sind, wo zB 3 Eigenschaften konstant sind und 2 variabel. Die 3 Konstanten würde in eine Tabelle aus Strukturen mit diesen 3 Konstanten liegen und das Objekt halt eine Index-Eigenschaft.

    Na gut. Wenn sie immer konstant sind (im ganzen Programm), dann sollten sie auch da liegen, wo sie gebraucht werden.

    Es wäre sehr hilfreich, wenn Du ein Baumdiagramm der wichtigen Sachen machen könntest.
    So zum Beispiel:
    Klasse1
    *Klasse2
    **Eigenschaft1
    **Eigenschaft2
    *Klasse3
    **Eigenschat3
    ...

    Denn so wirklich verstanden habe ich es immer noch nicht.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Ich habe ein paar Klassen zusammengefasst, da sie gemeinsame Eigenschaften haben. Diese sind halt eine Klasse geworden. Differenzieren sich aber durch deren TypeId. Diese Daten der Klasse müssen abgespeichert werden. Da aber manche konstant sind müssen sie ja nicht abgespeichert werden. Und ich überleg gerade ob die Speicherstruktur ich übernehmen kann oder ob diese erst umkonvertieren müsste.
    zZ Sieht das so aus :

    VB.NET-Quellcode

    1. Structure EntityFileBase
    2. Dim Id, X, Y, DataId, Health As UInt16
    3. Dim LookingIn As FaceDirection
    4. End Structure

    Da aber jede Entität gewisse Züge hat müssten die halt entweder nach dem Auslesen in eine 2. Klasse mit diesen extra Eigenschaften konvertiert werden oder ich lass es so und bestimme dieses über die Id-Eigenschaft. Die Hauptfrage kann hier wiederholt werden.

    Da ich nicht sicher bin was genau mit manchen Sätzen gemeint ist gehe ich mal alles nacheinander durch.
    Ich habe ein paar Klassen zusammengefasst, da sie gemeinsame Eigenschaften haben.

    Das heißt also Du hast aus diesem hier:

    VB.NET-Quellcode

    1. Class Klasse1
    2. Property X As Integer
    3. Property Y As Integer
    4. End Class
    6. Class Klasse2
    7. Property X As Integer
    8. Property Z As Integer
    9. End Class

    das hier:

    VB.NET-Quellcode

    1. Class BasisKlasse
    2. Property X As Integer
    3. End Class
    5. Class Klasse1
    6. Inherits BasisKlasse
    7. Property Y As Integer
    8. End Class
    10. Class Klasse2
    11. Inherits BasisKlasse
    12. Property Z As Integer
    13. End Class

    gemacht?

    Diese sind halt eine Klasse geworden. Differenzieren sich aber durch deren TypeId.

    Das heißt also, dass Du irgendwo eine List(Of BasisKlasse) hast. Und Du arbeitest mit den Einträgen darin so, dass Du anhand der ID herausfindest, ob es sich tatsächlich um Klasse1 oder Klasse2 handelt?

    Diese Daten der Klasse müssen abgespeichert werden.

    Also würde ich vorschlagen:

    VB.NET-Quellcode

    1. MustInherit Class BasisKlasse
    2. Property X As Integer
    3. Public MustOverride Function Serialize() As String
    4. End Class
    6. Class Klasse1
    7. Inherits BasisKlasse
    8. Property Y As Integer
    9. Public Overrides Function Serialize() As String
    10. Return "Klass1:Y=" & Y.ToString
    11. End Function
    12. End Class
    14. Class Klasse2
    15. Inherits BasisKlasse
    16. Property Z As Integer
    17. Public Overrides Function Serialize() As String
    18. Return "Klass2:Z=" & Z.ToString
    19. End Function
    20. End Class


    Da aber manche konstant sind müssen sie ja nicht abgespeichert werden.

    Nein. Wenn sie sowiso feststehen würde sich ein Abspeichern nie lohnen.
    Aber ich frage micht warum Du Konstanten in einer Klasse ablegst, die zum Halten von Daten dient.

    Und ich überleg gerade ob die Speicherstruktur ich übernehmen kann oder ob diese erst umkonvertieren müsste.
    ...
    Da aber jede Entität gewisse Züge hat müssten die halt entweder nach dem Auslesen in eine 2. Klasse mit diesen extra Eigenschaften konvertiert werden oder ich lass es so und bestimme dieses über die Id-Eigenschaft.

    Wenn ich das richtig verstanden habe hat sich das durch den Code oben erledigt.
    Jede Klasse weiß selbst wie sie abgespeichert werden muss. Da das alles über die Basisklasse aufgerufen werden kann machst Du nur

    VB.NET-Quellcode

    1. For each i As BasisKlasse In [Deine List(Of BasisKlasse)]
    2. DoSomething(i.Serialize)
    3. Next

    und zurückgegeben wird eine vollständige Textdarstellung Deiner Klasse
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Nicht so ganz. Ich habe eine Exceltabelle mit folgenden Spalten:
    Id,Name,Größe,Statisch,Aufnehmen,InteraktionId,MAXhealth,Health,Regen,Textur-ID
    Das ist die Wertetabelle. Wenn ich jetzt eine Entität von Id habe dann bleiben Werte wie MaxHealth oder TextureId ja gleich. Da ich ja keine Select Case nehmen will beim Updaten der Entitäten. Da ist IMO n Array von dieser konstanten Tabelle fast sinnvoller, weiß aber nicht ob das evtl. suckt wegen den vielen Zugriffen und ich müsste dieses Array so öffentlich machen, dass ich n paar Sachen umbauen müsste. Aber es wäre weniger Speicher benötigt. Die Entitäten werden zZ binär gesichert.

    Anscheinend spricht ja nur die Datenredundanz für das Array.
    Wenn es sich nicht um einige Milliarden Einträge handelt kann man die paar Bytes denke ich verkraften.
    Vor allem wird es übersichtlicher für Dich.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Naja, Du hast ja geschrieben
    Wenn ich jetzt eine Entität von Id habe dann bleiben Werte wie MaxHealth oder TextureId ja gleich. Da ich ja keine Select Case nehmen will beim Updaten der Entitäten. Da ist IMO n Array von dieser konstanten Tabelle fast sinnvoller

    Und ohne jetzt den Zusammenhang zwischen den gleichbleibenden Werten, dem Updaten, dem Select Case und dem Array zu kennen lese ich heraus, dass die Datenredundanz nur mit der Tabelle, aber nicht mit dem Array auftritt. Weiters lese ich, dass es mit dem Array komplizierter ist, und dass es möglicherweise (nicht fix) Performanceprobleme mit dem Array gibt.
    Diese negativen Gründe reichen für mich aus, um das einzig positive (die vermiedene Datenredundanz) auszugleichen. Darum würde ich bei der Tabelle bleiben.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Grob überschlagen könnte es sich um 6 bis 14 Byte pro Entität handeln bei geplanten. 30 - 150.

    Naja, was nicht muss muss nicht. Ich optimiere gerne wo geht.

    Wie gesagt ich denke, dass es besser ist, aber danke für das Zitat. Das war doch schon überlegenswert. Habe jetzt einen EntityHandler aufgesetzt der die Konstantendaten handlet sowieso das umwandeln von DateiEntitäten und ProgrammEntitäten. Für mich ist das alles übersichtlich und verständlich.

    Ich finds immer noch sinnvoller das Ganze zu abstrahieren, da nicht alles in die Serialisierten Welten muss, da vieles von denen konstant ist. Somit brauch eine Wertetabelle. Aber danke für den Rat.

    @FloFuchs: Das ist schon klar. Es liegen nur die geplanten Daten in einer Exceltabelle die immer geshared wird zwischen den Ideensammlern.

    @nikeee13: zZ setze ich die Planung nur in VB um, geplant ist das Ganze eher in C++. Da könnte ich mir so eine Basisklasse machen von der ich erbe, aber was soll mir das genau bringen. Ich habe den Text noch nicht ganz gelesen, weil ich grad weniger Zeit habe, aber ich habe die Funktionen überflogen.

Facebook
Telefonspende