Aggregate Objekte

Question

Wenn Sie eine Klasse A, die ein Aggregat der Klasse B und C ist, ist es für einen besseren

• speichern IDs für B und C
• zu laden und speichern das gesamte Objekt für B und C (Bearbeiten, zu speichern durch Bezugnahme B/C Objekt, also Instanziieren Objekte B und C, im Gegensatz zu IDs für B und C.
• speichert die IDs und stellen Verfahren Methoden speichern B und C

ziehen

Ich gehe davon aus, dass dies je nach perf variiert ormance Anforderungen und andere Anforderungen, aber ich suche nur nach allgemeinen Richtlinien oder Gedanken.

Answer 1

In einem typischen Programm, das im Speicher ausgeführt wird, werden Objekte fast immer durch Referenz als Zeiger gespeichert, so dass Sie IDs für B und C speichern, nur dass Sie nicht mit den Details selbst arbeiten, die Sprache verbirgt sie von dir.

Das Laden und Speichern des "gesamten Objekts" ist ein fragwürdiges Konzept. Ich weiß, dass du versuchst, sprachunabhängig zu sein, aber eines der ersten Dinge, die mir wirklich geholfen haben, OO zu "holen", ist, dass fast jedes Objekt einen eigenen Lebenszyklus haben sollte.

Wenn Sie Objekt A haben, das Objekt B enthält, und Sie einen Verweis auf Objekt B an Objekt C übergeben, dann muss Objekt A etwas über Objekt C wissen, das ist völlig NICHT OK. Das Freigeben des Lebenszyklus von Objekt B, sodass Objekt A nichts über Objekt C weiß, ist eines der Kernkonzepte, die OO zum Funktionieren bringen.

Wenn Sie also das gesamte Objekt speichern wollten, dann tun Sie das nicht.

Und das gilt auch für Datenbanken und anderen Speicher. Selbst wenn ein Objekt dafür verantwortlich ist, ein anderes zu zerstören, sollte es selten die Daten der anderen Objekte enthalten.

Und obwohl ich denke, dass Sie sagen wollten "Objekte B und C ziehen", nicht "Methoden"), ist das Konzept, ein Objekt von einem anderen zu trennen, ebenfalls sehr nützlich und es ist im Allgemeinen nichts falsch daran mit einem Vorbehalt:

Denken Sie daran, dass ein Objekt keine Kontrolle darüber hat, was sich außerhalb von sich selbst abspielt. Es kann herumgereicht werden, Methoden, die in einer zufälligen Reihenfolge aufgerufen werden, usw. Daher ist es hilfreich, Ihr Objekt so sicher wie möglich zu halten. Wenn etwas in der falschen Reihenfolge aufgerufen wird oder eine ungültige Variable übergeben wird oder Sie feststellen, dass Sie irgendwie einen ungültigen Status eingegeben haben, schlagen Sie früh fehl und fällen Sie LOUD, so dass der Programmierer, der einen Fehler gemacht hat, diesen aufgerufen hat.

Sie möchten es auch so schwer wie möglich machen, in einen unzulässigen Zustand zu gelangen - das bedeutet, Ihr Objekt klein und einfach zu halten, Variablen möglichst abschließend zu machen und nicht zu viele Stellen zu haben, an denen Parameteraufrufe wichtig sind.

Answer 2

Dies hängt von der Situation ab. Wenn die Objekte im Speicher bleiben, ist es mehr OO (und einfacher), dass A B und C enthält. Ich habe herausgefunden, dass, wenn die Objekte beibehalten werden müssen, es die Dinge einfacher und effizienter macht, für die IDs zu speichern B und C (auf diese Weise, wenn Sie Daten direkt in A benötigen, aber nicht B und C, Sie müssen nicht zu B und C aus der Datenbank, Datei usw. ziehen)

Answer 3

Es hängt davon ab,

Wenn B und C schwer sind und Aufwand zum Laden und Konstruieren erfordern, kann es sich lohnen, das Laden von ihnen aufzuschieben, bis Sie sicher sind, dass sie benötigt werden (Lazy Initialize).

Wenn sie einfach und leicht sind, möchten Sie sie vielleicht nur dann konstruieren, wenn Sie die IDs erhalten.

Answer 4

Ich neige dazu, die gesamten Objekte (und ihre Unterobjekte) als meine Standardmethode zu laden und zu speichern.

Manchmal führt dies zu langen Ladezeiten, einem großen Speicherbedarf oder beidem. Dann müssen Sie feststellen, ob alle geladenen Objekte tatsächlich verwendet werden oder ob viele erstellt wurden und nie zugegriffen wurde. Wenn alle Objekte verwendet werden, ist ein kreativerer Ansatz erforderlich, um eine Teilmenge zu laden, zu verarbeiten, zu verwerfen und dann die nächste Teilmenge zu laden, um alles in den Speicher zu packen - oder einfach mehr Speicher zu kaufen und verfügbar zu machen zu deiner App

Wenn viele der Objekte nicht verwendet werden, ist es am besten, die Unterobjekte langsam zu laden, wenn sie benötigt werden.