Objekte verheiratet - Wie am besten moddelieren ?



  • Eventuell sollte man sich überlegen, das ganze eher über ein standesamt verwalten zu lassen. Die Implementierung könnte dann z.B. über eine (multi-) map laufen und die Schnittstelle so aussehen:

    partnerschaft_registrieren(person p1, person p2)
    

    (Je nach gesellschaftlicher Freiheit müsste man das ersetzen durch 'mann' und 'frau' oder auch durch eine Schnittstelle, welche mit mehreren Partern umgehen kann.)

    Eine Person sollte dann höchstens einen Verweis auf seinen Partnerschafts-Register erhalten (ähnlich der lebensgemeinschaft* ).



  • Über ein Verwaltungsobjekt kann man auch personenbezogene Beziehungseigenschaften bestimmen:

    class Eheverwaltung
    {
        vector< pair<Mensch*, Mensch*> > m_beziehungen;
    public:
        bool lebtPolygam(Mensch *m)
        {
            size_t nBeziehungen = 0;
            for(size_t iBeziehung = 0; iBeziehung < m_beziehungen.size(); ++iBeziehung)
                if(m_beziehungen[iBeziehung].first == m || m_beziehungen[iBeziehung].second == m)
                {
                    ++nBeziehungen;
                    if(nBeziehungen > 1)
                        return true;
                }
            return false;
        }
    };
    

    So kann man feststellen, ob ein Mensch polygam oder monogam lebt, ohne dass sein/e Partner ebenfalls mono/polygam leben müssen.



  • wie wärs damit.

    class Familie;
    class Mensch
    {
    private:
    	Familie** familie;
    public:
    	void heiraten(Mensch* partner);
    };
    class Mann : public Mensch
    {
    
    };
    class Frau : public Mensch
    {
    public:
    	Mensch* kindKriegen();
    };
    class Familie
    {
    public:
    	static enum BeziehungsArt {Ehefrau,Ehemann,Vater,Mutter,Sohn,Tochter};
    
    	void beziehungSetzen(Mensch* m1,Mensch* m2,BeziehungsArt);
    private:	
    	multimap<pair<Mensch*,Mensch*>,BeziehungsArt> Beziehungen; 
    };
    

    Beziehungen zwischen 2 Menschen werden einfach in einem gemeinsamen Familien Objekt gespeichert. Dadurch ensteht ein ganzer Stammbaum, möchte man mehr Informationen über Beziehungen speichern kann man aus dem enum BeziehungsArt eine eigene Klasse machen.



  • HI,

    klar - man kann immer mehr Aspekte einfügen (vielleicht sind ja auch frühere Ehen und Kinder relevant ? Und das Standesamt ist ja auch noch einer Behörde unterstellt, ...) ...
    Deswegen finde ich den Versuch, das "ultimative Modell" zu finden, doch eher amüsant. Letztlich wird der Kunde entscheiden müssen "wieviel und welche Realität" er abgebildet haben (und bezahlen und bedienen) möchte.

    Gruß,

    Simon2.



  • HumeSikkins schrieb:

    Das "ein Pointer auf den Partner" reicht, geht implizit von einer monogamen Gesellschaft. Wenn ich nun aber alle meine sieben Frauen heiraten will, hat das Design ein Problem.

    dann tauscht man einfach den member Mensch ehepartner; gegen einen std::vector<Mensch> ehepartner; 😉



  • pale dog schrieb:

    dann tauscht man einfach den member Mensch ehepartner; gegen einen std::vector<Mensch> ehepartner; 😉

    LOL 😃

    🙂 👍



  • hustbaer schrieb:

    Und wenn Schreiben vielen blödsinn dann auch Brauchen nix grammatik Deutsches.

    Und wenn man viel blödsinn schreibt, dann braucht man auch nicht grammatikalisches Deutsch.



  • HumeSikkins schrieb:

    Allerdings sollte man das auch nicht blind machen, da dieser Ansatz auch seine Probleme (= zusätzliche Abhängigkeiten) mit sich bringt: wie, wie oft und wo wird die Mediator-Klasse instanziiert? Müssen die Elemente der Relation (hier die Menschen) die Mediator-Klasse kennen? Per Referenz? Wer setzt diese? Per Parameter? Wer übergibt diesen?
    Übertreibt man diesen Ansatz, erzeugt man außerdem häufig Klassen, die entweder nur Daten (aber kein interessanten Verhalten) oder nur Verhalten (und keine Daten) besitzen. Das hat zwei Nachteile: zum einen führt es zu einer vielzahl von Klassen (reales Problem),

    100% ACK. sowas muss sauber skalariert werden.

    HumeSikkins schrieb:

    zum anderen war das ursprünglich Ziel der OOP mal, Daten und Verhalten zu kombinieren (akademisches Problem, da diese Sichtweise mittlerweile nicht mehr aktuell ist, wie man an vielen DPs sehen kann).

    Beziehst Du die Dich auf den (GoF)Imperativ "Vererbe Schnittstellen, nicht Implementierungen!"?

    Btw "DPs" ?!? 😕

    Grüsse

    *this



  • Gast++ schrieb:

    Btw "DPs" ?!? 😕

    design patterns 🙂



  • ty2u! 🙂


Anmelden zum Antworten