Clevere Objektverwaltung

knivil

Social oder Race. Jede Instanz von Citizen hält einen Pointer auf eine Instanz von Social, Race usw.

Warum alles mit Pointern? Einfach normale Member verwenden. Genauso deine City, warum kann die nicht einfach eine Liste von Buergern verwalten anstatt eine Liste von Pointern?

KayMcRay

knivil schrieb:

Warum alles mit Pointern? Einfach normale Member verwenden. Genauso deine City, warum kann die nicht einfach eine Liste von Buergern verwalten anstatt eine Liste von Pointern?

Ich verstehe glaube ich nicht ganz, was du mir damit sagen willst!? Ich soll die Member in der jeweiligen Citizen oder City Instanz speichern? Aber was ist wenn eine andere Instanz von Citizen die gleiche Social braucht? Dann müsste ich ja eine Kopie anlegen. Und dazu kommt ja, dass die City-Instanzen dynamisch zur Laufzeit angelegt werden - der Spieler baut ja seine Städte. Es würde schon von der Warte her - für mich - keinen Sinn machen die schon bei Pogrammstart angelegten Instanzen der Bügergattungen in einem temporalen Objekt abzuspeichern...
Bin ich jetzt auf dem Holzweg und/oder hab ich dich überhaupt richtig verstanden?

Oder meinst du, dass die Bürger einfach normale Member der City sein sollen? Das habe ich versucht zu erklären mit dem Indentifzierer. Irgenwoher muss ich ja die besonderen Paramter der Bürgergattung nehmen.
Falls einer von euch die Anno-Reihe kennt, mit der versuch ich es mal zu erklären. Da gibt es Aristrokraten, die wollen Schmuck "essen" und "Stoff" die Siedler wollen nur "Stoff" essen. Wenn ich in der Instanz des Hauses abspeichere: Der ist Aristrokrat oder der ist Siedler, würde das an der Stelle freilich reichen, aber ich brauche nach wie vor ein Objekt, das speichert was der Aristrokrat essen will. Also ist es doch im Endeffekt irrelvant ob ich einen Pointer auf die Typisierungsklasse des Aristrokraten halte oder einen Indentifizierer, den eine extra Funktion in einen Pointer umwandeln muss!?

Vor meinem geistigen Auge sieht das jetzt so aus:

struct race{ };
struct social{ };
struct religion{ };
...

struct citizen{
  race* race_;
  social* social_;
  religion* religion_;
  ...
};

struct city{
  struct crowd { citizen* c; int card;};
  std::vector<crowd> inventory;
};

Richtig?

Jetzt willst Du alle Instanzen von citizen und city gemeinsam verwalten? Also haben die beiden doch gemeinsame Eigenschaften?

KayMcRay

Hey Furble Wurble, dein geistiges Auge hat das schon ziemlich gut erfasst.
City und Citizen sollte nicht unbedingt gemeinsam verwaltet werden, weil City-Instanzen zur Laufzeit verändert werden und Citizen-Instanzen entweder hardcoded sind oder bei Programmstart aus ner File gelesen werden.
Also wenn dann Citizen und seine Module Race, Social, etc. gemeinsam verwalten.
Für die City-Instanzen hätte ich einfach einen vector im hauptprogramm verwendet.

knivil

Wenn ich in der Instanz des Hauses abspeichere: Der ist Aristrokrat oder der ist Siedler, würde das an der Stelle freilich reichen, aber ich brauche nach wie vor ein Objekt, das speichert was der Aristrokrat essen will.

Warum in der Instanz des Hauses, warum nicht in der Instanz des Buergers.

Btw. beantworte bitte folgende Frage: Ist ein Aristrokrat ein Buerger? Wenn ja, dann impliziert das nach OOP folgendes in C++:

class Aristrokrat : public Buerger { 
public:
    virtual std::vector<Gueter> bedarf() const;
...

wobei bedarf durch das Interface Buerger ueberschrieben wird.

Das ist nur eine Moeglichkeit. Aber ich halte es fuer schlecht, globale Instanzen wie Race etc. zu haben, auf die mit Pointer verwiesen wird.

KayMcRay

@knivil
Das ist unter anderem das worauf ich hinaus wollte.
Der Fall des Aristokraten hört sich an, als handelt es sich um eine solche Hirarchie.

Aber:
Aristokrat ist kein Bürger sondern nur eine Sammlung von Eigenschaften. Ein Social eben. Jeder Social hat die gleichen Member, aber unterschiedliche Parameter. Eben wie im Post von Furble Wurble richtig erkannt. Ich bin gerne bereit mein Design zu überarbeiten. Dafür müsstest du mir aber ein gutes Argument liefern, warum der von mir angestrebte modulare Aufbau dem des hierarchischen unterlegen sein soll.
Desweiteren hätte ich das Problem der Objektverwaltung nach dem strikten OOP immer noch nicht gelöst. Ich hätte jetzt zwar einen Aristokraten, der den Stuff von Bürger erbt. Aber nach wie vor müsste ich in einem Haus abspeichern welcher Bürger da wohnt - das impliziert wieder die Verwendung von Referenzen / Pointern. Wobei ich wieder bei der Frage wäre wo und wie speichere ich am cleversten meine Bürgersammlung.

daddy_felix

KayMcRay schrieb:

Aber nach wie vo müsste ich in einem Haus abspeichern welcher Bürger da wohnt - das impliziert wieder die Verwendung von Referenzen / Pointern.

Was spricht gegen

class Haus
{
  std::vector<Buerger> m_bewohner;
};

KayMcRay

daddy_felix schrieb:

KayMcRay schrieb:

Aber nach wie vo müsste ich in einem Haus abspeichern welcher Bürger da wohnt - das impliziert wieder die Verwendung von Referenzen / Pointern.

Was spricht gegen
class Haus
{
  std::vector<Buerger> m_bewohner;
};

Dann müsste ich entweder meine im Vorfeld angelegten Bürger immer wieder kopieren oder aber zur Laufzeit die Bürgereigenschaften aus einer File auslesen. Das für jedes Haus!? Eher nicht. Deswegen die Bürger bei Programmstart anlegen und auf sie zeigen. Nach wie vor können auch hundert Häuser gleichzeitig einen Bewohner vom Typ Aristokrat haben, ohne, dass ich jedesmal eine neue Instanz von Aristokrat oder Bürger anlegen will. Wozu auch?

knivil

Dafür müsstest du mir aber ein gutes Argument liefern, warum der von mir angestrebte modulare Aufbau dem des hierarchischen unterlegen sein soll.

Jeder Ansatz hat Vor- und Nachteile. "Unterlegen" ist Ansichtssache und du hast deine Wahl getroffen.

Ein wichtiges Kriterium fuer mich ist Komplexitaet. Ein Aspekt dabei sind Abhaengigkeiten und Querverweise. Deine Buerger sind abhaengig von statischen Objekten und haben allerlei Querverweise durch Pointer auf diese. Logische Konsequenz waere eine Buergerfactory zu entwerfen, die mir diese Abhaengigkeiten aufloest ... noch mehr Komplexitaet, Abhaengigkeiten etc.

KayMcRay

knivil schrieb:

Logische Konsequenz waere eine Buergerfactory zu entwerfen, die mir diese Abhaengigkeiten aufloest ... noch mehr Komplexitaet, Abhaengigkeiten etc.

Kannst du bitte ein wenig mehr ins Detail gehen? Ich verstehe nicht so ganz worauf du hinaus willst. Bzw. Links zu Büchern oder Blogs sind eben so gerne gesehen.