Ich möchte ein Strategiespiel machen, und zwar im Stil von Siedler. ( Nur in der Konsole. )
Habe also Häuser, Arbeiter und Waren, diese sollen transportiert werden.
Hab mir dazu auch schon ne Vererbungshierarchie ausgedacht:

// Pseudo UML ;)

     Building                       Worker
    /   |      \                 /     |    \         
   /    |       \               /      |     \        
Farm   Mill    Bakery        Farmer  Miller  Baker    Bearer (Träger)

       Good
    /   |    \  
   /    |     \       
Wheat  Meal  Bread

Building              Worker             Bearer
-----------           --------           --------
Worker*               Building*          Source (Building)* 
Raw(Good)*                               Target (Building)*	
Product(Good)*
Entry
Exit

Good
-----------
Stacksize

Nun weiss ich nicht recht, wie ich die Beziehung untereinander machen soll. Der Träger sollte zum Haus gehen, wenn da Waren liegen, und diese zum nächsten bringen. Der Müller soll dann anfangen zu mahlen, wenn er etwas Weizen bekommen hat. Und so weiter..
Ich könnte nun einerseits in jeder Runde mit if Abfragen alle Gebäudeein und ausgänge auf Waren prüfen, aber das scheint mir nicht die beste Lösung zu sein.
Hätte jemand einen Designvorschlag?
Da gibts doch sicher so ein tolles "Pattern" was geeignet ist

Der Müller soll dann anfangen zu mahlen, wenn er etwas Weizen bekommen hat.

Wenn das eigentich: "Der Müller soll dann anfangen zu mahlen, wenn die Mühle Weizen bekommen hat." heißen soll dann klingt das sehr stark nach Observer-Pattern.

//Pseudocode:
muehle.addListener(mueller);

...

void Muehle::handleWeizenBekommen ()
{
    for(all listeners)
        listener.weizenDa();
}

...

Mueller extends MuehleListener
{
    virtual void weizenDa () { beginneZuMuehlen(); 
};

MfG SideWinder

Dann muss nur noch die Mühle ein Event werfen, wenn sie neues Mehl zum Abholen hat. Der Träger ist dann EventListener und speichert das dann. Sobald er Zeit hat holt er dann das Mehl und bringt es zum Bestimmungsort.

MfG SideWinder

Zu deinem Codebrocken, was heisst "extends"?

Werde mal nach Observer googlen...
Danke!!

Zu spät gesehn, hast recht, brauche nur die Träger. ( Bin friedliebend )

Klar kenn ich die Siedler (II versteht sich). Und wenn du ein wenig "generischer" denken würdest wäre das kein Problem :). hasMiller ist Quatsch, aber die Basisklasse der "einfachen" Gebäude (Brunnen, Bäckerei, Fleischerei, Sägewerk und eben auch die Mühle) braucht nur eine Variable, die anzeigt, ob das Gebäude besetzt ist.
Wenn ein neues Gebäude gebaut ist schaust du im Lager nach, ob du die nötigen Werkzeuge und einen Siedler hast, generierst einen mit dem entsprechenden Beruf und lässt ihn dann vom Lagerhaus oder Hauptgebäude zu seinem Arbeitsplatz laufen. Ist er da angekommen wird "istBesetzt" gesetzt und das Gebäude nimmt die Waren an.
Mit Trägern kannst du es ähnlich machen, deren "Arbeitsplatz" ist dann halt zwischen 2 Fahnen (vorausgesetzt du willst das echte Wegsystem benutzen.

extends ist dann in dem Fall
class Muhele : public MuehleListener

MfG SideWinder

Danke an euch, ich wurschtel dann mal weida..
greez

Hab dank der Forensuche das hier gefunden, und die Klassen Observer und Observable so ähnlich implementiert. Funktioniert auch soweit.
So und nun Leite ich die Klassen Farm, Mill, Bakery und Path von den beiden und vom Basistyp Building ab. Nun will ich im Baumenu natürlich Instanzen erzeugen, mit new.
Meine Frage ist nun, wo pack ich die rein?
In nen Vektor für jeden Gebäudetyp, oder alle in einen für den Basistyp Building?
Ich dachte ich mach ne Klasse Village (o.ä) wo ich nen Container für bereitstelle. Macht das irgendwie Sinn?

Wo findet man eigentlich all die Patterns, und weiss wann man welches einsetzt. Ist das Erfahrung oder gibts da ein Schema F?

dann gibt es noch "das" referenzwerk von der "gang of four" mit dem gleichnamigen titel "design pattern". das buch ist allerdings ziemlich trocken, und schwer verständlich, wenn man nicht wirklich fit im objekt-orientiertem design ist. dafür aber sehr vollständig (was die enthaltenen patterns betrifft) und somit ein sehr gutes nachschlagewerk.
sehr viel lebendiger ist das buch von head first:
http://www.amazon.de/gp/product/0596007124/302-2971792-6420869?v=glance&n=52044011
Das gibts auch auf deutsch, ist aber 20€ teurer und bei übersetzungen weiss man nie so recht ;).

auch nicht schlecht ist diese seite: http://www.dofactory.com/Patterns/Patterns.aspx. die erklärungen sind allerdings nicht besonders ausführlich, deswegen ist es auch eher als nachschlagewerk zu gebrauchen, für den fall, dass dir im forum ein "Abstract Factory" an den kopf geworfen wurde ;).

Und ne andere Frage ist nun, ein Gebäude das sowohl Waren empfängt und bereitstellt (fast alle ausser der Farm) erbt doch nun von 3 Klassen allein durch die Observer und Factory Geschichten. Zusätzlich dachte ich ja an eine Basisklasse Building. Das wären dann 4 Basisklassen. Ist das nicht etwas komplex bzw. ein unnötiger Overhead?

Letzte Frage für den Moment: Gibt es die Funktion GetType().Name auch bei C++ oder nur bei C#?

Meine Grundfrage von vorhin bleibt aber, wo speichere ich die erzeugten Objekte?
In ner Extraklasse Village in nem Vector für Products?
Gibts da etwa noch ein Manager Pattern

Brauchst du gar nicht. Du wirst ja irgendwo die ganzen Daten des Spielers abspeichern (z.B. auch die Position des Hauptgebäudes, das Volk, Statistiken etc.). Da kannst du einen Gebäude-Vektor einfügen. Aufgrund der Verwendungsart als Container ausschließlich polymorpher Objekte solltest du ptr_vector verwenden. IIRC funktioniert der auch mit Boost.Serialization, sehr praktisch für Spielstände.

Ooptimist schrieb:

Und ne andere Frage ist nun, ein Gebäude das sowohl Waren empfängt und bereitstellt (fast alle ausser der Farm) erbt doch nun von 3 Klassen allein durch die Observer und Factory Geschichten. Zusätzlich dachte ich ja an eine Basisklasse Building. Das wären dann 4 Basisklassen. Ist das nicht etwas komplex bzw. ein unnötiger Overhead?

Du kannst noch einige Abstraktionen machen, z.B. eine Producer-Klasse die von Building abgeleitet ist und eine Receiver-Klasse, die wiederum von Producer abgeleitet ist (die "Ist-ein" Beziehung ergibt sich aus der Spiellogik, wenn du dich an die Siedler-Regeln hältst, sollte aber dennoch gut dokumentiert sein. Militärgebäude sind zwar auch Empfänger, aber wenn du nur deshalb Receiver nicht von Producer ableiten würdest, dann müsstest du Producer und Receiver virtuell ableiten, was hier aber nicht praktisch ist. Militärgebäude "verarbeiten" die ankommenden Rohstoffe ja auch ganz anders.

Ooptimist schrieb:

Letzte Frage für den Moment: Gibt es die Funktion GetType().Name auch bei C++ oder nur bei C#?

Nein. Es gibt nur typeid(typ).name, aber das ist nicht eindeutig. Wenn du so etwas haben willst, dann implementier es als virtuelle Methode.

.filmor schrieb:

Ooptimist schrieb:

Und ne andere Frage ist nun, ein Gebäude das sowohl Waren empfängt und bereitstellt (fast alle ausser der Farm) erbt doch nun von 3 Klassen allein durch die Observer und Factory Geschichten. Zusätzlich dachte ich ja an eine Basisklasse Building. Das wären dann 4 Basisklassen. Ist das nicht etwas komplex bzw. ein unnötiger Overhead?

Du kannst noch einige Abstraktionen machen, z.B. eine Producer-Klasse die von Building abgeleitet ist und eine Receiver-Klasse, die wiederum von Producer abgeleitet ist (die "Ist-ein" Beziehung ergibt sich aus der Spiellogik, wenn du dich an die Siedler-Regeln hältst, sollte aber dennoch gut dokumentiert sein. Militärgebäude sind zwar auch Empfänger, aber wenn du nur deshalb Receiver nicht von Producer ableiten würdest, dann müsstest du Producer und Receiver virtuell ableiten, was hier aber nicht praktisch ist. Militärgebäude "verarbeiten" die ankommenden Rohstoffe ja auch ganz anders.

Ok sorry, ich kapiers nicht mehr
Im Observer-Pattern hab ich Observers und Observables, in der Factory hab ich Creators und Products. Kann ich die Factory und Observer Methoden nicht in die Basisklasse der Bereitsteller und Empfänger einfügen? Ich hab ja sonst ewig viele Abhängikeiten und Dateien, ich hab einfach keinen Überblick mehr, was wo ist

Factory						Observer

Creator      Product          Subject      Observer    
   |            |                |            |
   |            |                |            |
   |            |                |            |
Builder ---->Building            |            |
   |            |                |            |
   |            |                |            |
   |            ---------------| |  --------| |
   |                          Pure          Pure
   |                          Producer      Receiver
   |                          |   |          |    | 
   |                          |   |          |    |
   |                          |   ----| |-----    |
   |                          |    Processor      |
   |                          |        |          |
   |                          |        |          |
   |                          |        |          |
Farm* Builder ------------>Farm   Mill/Bakery  Storage       
*needed for each
spec. Building Type

Macht das Sinn so? Kritik wäre toll!

schau dir doch einmal www.widelands.org an. Widelands ist ein Spiel, das Siedler II sehr sehr ähnlich ist. Das Spiel ist Opensource, du kannst dir also einmal den Quellcode herunterladen und ansehen wie dort das Klassendesign realisiert wurde.

Ciao

Nochmal, willst du dich wirklich genau an die Siedler II halten?.

Nein eigentlich nicht. Schongar nicht Siedler II, wenn schon das erste Habe nur das Prinzip gemeint, Bauspiel mit Wirtschaftssystem und Transport etc. aber ohne Milität. Ich mags friedlich.

.filmor schrieb:

Dann gibt es keine Pure Receiver (außer Militärgebäude). Das ist das worauf ich beim letzten eingehen wollte.
Das Farm ein Pure Producer ist ist genauso falsch (eine Farm nimmt Wasser an), wie dass Storage ein Pure Receiver ist (Lagerhäuser musst du definitiv gesondert behandeln).

Ok, habs nicht genau genug gelesen. Du meintest die Reciever vom Producer ableiten. So gehts dann natürlcih. In meinem System soll es aber reine Produzenten geben, die Farmen, denn Wasser regnets vom Himmel Am Ende der Kette stehen Konsumenten. Die werd ich dann wohl nochmal extra machen und nur vom Observer ableiten.

.filmor schrieb:

Zusätzlich heißt ein Pattern benutzen nicht zwingend, dass du deine Klassen auch direkt von den Observable etc. ableiten musst (hast du auch nicht getan und richtig erkannt) Das gehört in die (richtige) Basisklasse, dann ergibt sich alles implizit aus der Vererbungshierarchie. Deshalb hast du eine (fast) lineare Vererbung und daher fast keinen Overhead. Um virtuelle Methoden wirst du eh nicht herumkommen.
Der sinnlose und unschöne Overhead ergibt sich erst, wenn du sowohl von Pure Receiver als auch Pure Producer ableitest (wie hier bei Mill/Bakery), such zu dem Thema mal nach dem "deadly diamond". Siehe auch mein letztes Posting.

Den "deadly diamond" kenn ich, ist mir gar nicht aufgefallen in meinem "Diagramm". Gibt halt noch keine UML Tags für dieses Forum

Also jetzt aber

.filmor schrieb:

Nochmal, willst du dich wirklich genau an die Siedler II halten?.

Nein eigentlich nicht. Schongar nicht Siedler II, wenn schon das erste Habe nur das Prinzip gemeint, Bauspiel mit Wirtschaftssystem und Transport etc. aber ohne Milität. Ich mags friedlich.

Hey, was ist gegen S2 einzuwenden? Außerdem unterscheidet sich das Regelwerk doch iirc nicht besonders ...

Ooptimist schrieb:

Ok, habs nicht genau genug gelesen. Du meintest die Reciever vom Producer ableiten. So gehts dann natürlcih. In meinem System soll es aber reine Produzenten geben, die Farmen, denn Wasser regnets vom Himmel Am Ende der Kette stehen Konsumenten. Die werd ich dann wohl nochmal extra machen und nur vom Observer ableiten.

Welche Konsumenten?! Ohne Militärgebäude sind nur die Lagerhäuser "Konsumenten".

Ooptimist schrieb:

Den "deadly diamond" kenn ich, ist mir gar nicht aufgefallen in meinem "Diagramm". Gibt halt noch keine UML Tags für dieses Forum

Man braucht kein UML, dass musst du spüren, junger Padawan ;). Im Ernst, wenn es zwei Vererbungspfade zur Basisklasse gibt hast du automatisch den "Diamanten des Todes" (klingt cooler ;)) und den gilt es imo zu vermeiden.

/edit Joa, das letzte Diagramm sieht gut aus. Übrigens, die Creator Objekte (bitte nicht Builder, dass ist mehrdeutig) kannst du schön in ein Template verfrachten.

Naja, die Konsumenten halt. Irgendjemand geht dann zum "Bäcker" und kauft sich ein "Brot" und "isst" das dann. ( Auf den Farmen wächst kein Wheat sondern Weed, aber pssst.. )

Ich finds halt graphisch dargestellt viel übersichtlicher, machs bei mir aber immer auf Papier. Nix UML. Mit Ascii Art ist halt etwas unschön, aber Du bist ja draus gekommen
Jetzt ists aber besser oder?

Das kannst du dann bei deiner Factory als Standardparameter nehmen:

template <typename Product>
class Factory
{
public:
    // ...
    typedef boost::function0<Product*> creator_type;
    // ...
    template <typename T>
    void register_ (id_type id, creator_type f = generic_creator<T>())
    {
        register_creator (id, f);
    }
};

register_creator ist dabei deine "normale" Registrierfunktion.
Und

fac.register_<Farm> ("Farm");

sieht doch nett aus und ist leicht in ein Makro zu fassen (auch wenn man damit sehr vorsichtig sein muss).

Du kannst diesen "generic_creator" und den creator_type natürlich noch abändern, so dass er Parameter entgegen nimmt (hier ist der einzig sinnvolle wohl der Bauplatz).