Objekte verheiratet - Wie am besten moddelieren ?

Simon2

inp schrieb:

...

...
class christiliche_ehe: public lebensgemeinschaft
{
 //impl details
 mensch m_mann
 mensch m_frau; 
};

class mormonische_ehe: public lebensgemeinschaft
{
 //impl details
 mensch m_mann;
 mensch m_frau[3];
};

Heißes Thema ... allein schon, weil die Mormonen sich auch als "Christen" verstehen.
monogame_ehe und polygame_ehe wäre vielleicht unverfänglicher

(wobei ich monogame im Englischen ja eine interessante Nebenbedeutung hat :D)

Gruß,

Simon2.

inp

Simon2 schrieb:

inp schrieb:
...
...
class christiliche_ehe: public lebensgemeinschaft
{
 //impl details
 mensch m_mann
 mensch m_frau; 
};

class mormonische_ehe: public lebensgemeinschaft
{
 //impl details
 mensch m_mann;
 mensch m_frau[3];
};
Heißes Thema ... allein schon, weil die Mormonen sich auch als "Christen" verstehen.
monogame_ehe und polygame_ehe wäre vielleicht unverfänglicher

(wobei ich monogame im Englischen ja eine interessante Nebenbedeutung hat :D)

Gruß,

Simon2.

hehe
erwischt
/me vom lynchen wegrenn

Konrad Rudolph

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.

walljumper

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.

Simon2

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.

pale dog

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;

proggingmania

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.

Gast++

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

inp

Gast++ schrieb:

Btw "DPs" ?!?

design patterns

Gast++

ty2u!