ne Frage die mir heute irgendwie eingefallen ist:

class Mensch {
   // ...
};

//...

Mensch Tina,Chris;

heiraten(Tina,Chris);

Wie sollte am besten Mensch dafür aussehen ?
Vllt so:

class Mensch {
   Mensch* lebenspartner;
};

void heiraten(const Mensch& a, const Mensch& b)
{
    a.setPartner(&b);
    b.setPartner(&a);
}

Oder wie stellt man am besten so eine Beziehung dar ?

Langfassung: Ja, so hätte ich es wohl auch modelliert (eventuell mit einigen Abfragen, damit niemand sich selber heiraten kann etc).

CStoll schrieb:

... etc.

Ganze etc wurde mal weggelassen

Das Entkoppeln solch Symetrien (hier Scheidung, Todesfall) wird nämlich spätestens dann unlustig wenn Nebenläufigkeit ins Spiel kommt.

Grüsse

*this

Mir gefällt's bessere wenn man solche Symetrien von einer dritten Grösse verwalten lässt; hier kommt die Klasse "Mensch" in Betracht die Indices verwaltet.
(Oder halt das Standesamt )

Hmmm, das mit dem dritten gefällt mir viel besser. Naja es kommt auch darauf an, wie komplex dann sowas werden sollte etc ...

class Kind : public Tina, public Chris

class lebensgemeinschaft
{
 //irgend n interface
};

class mensch
{
 //keine info über mann, frau, kind
 //eher vielleicht pointer auf die lebensgemeinschaften in denen sich dieser mensch bewegt
 lebensgemeinschaft* ehe;
 lebensgemeinschaft* familie;
};

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];
};

class familie: public lebensgemeinschaft
{
 mensch *m_naheverwandschaft;
 mensch *m_entferntevewandschaft;
 ...
}

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.

Prinzipiell würde ich solche (dynamischen) Relationen auch immer in einer dritten Klasse speichern. 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), 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).

Hallo,
das Beispiel zeigt mal wieder, dass man ohne Analyse der Domäne kein vernünftiges Software-Design erstellen kann.

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.

Prinzipiell würde ich solche (dynamischen) Relationen auch immer in einer dritten Klasse speichern. 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), 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).

naja, da stellt sich natürlich die frage auf was man als objekt auffast
entweder ein reines datenobjekt, oder ein rein funktionales objekt, oder eine kombination aus beiden. ich für meinen teil finde die gegebene möglichkeit in c++ alle 3 sorten zu haben sehr gut, um jeder streng abgrenzbaren "bedeutung von etwas" eine klasse(daten), bzw funktion zu geben.

zurück zum problem,
das modellieren des problems, auf welcher ebene es sich befinden muss(statisch bereits bekannt zur compilezeit oder dynamisch objekte können verschiedene formen von partnerbeziehungen haben), und wieviel flexibilität notwendig sein soll, über sowas muss man sich als entwickler natürlich im klaren sein.
wenn das programm sich in einer monogamischen gesellschaft bewegt, mann ganz genau weiss das sich das NIE und nimmer ändern wird, und aus codetechnischen gründen es einfach angenehmer ist den kürzeren weg zu gehen.
reicht pointer auf partner

falls aber eine "welt" simulation mit allen ecken und winkeln entstehen soll muss man den langen weg gehen.

...
wenn das programm sich in einer monogamischen gesellschaft bewegt, mann ganz genau weiss das sich das NIE und nimmer ändern wird, und aus codetechnischen gründen es einfach angenehmer ist den kürzeren weg zu gehen.
reicht pointer auf partner
...

Auch wenn es nur Monogamie gäbe, könnte dieser Ansatz zu Problemen führen. Was ist, wenn das Programm plötzlich darüber Auskunft geben soll, welche Ehen in einem bestimmten Zeitraum geschlossen wurden?

inp schrieb:

...
wenn das programm sich in einer monogamischen gesellschaft bewegt, mann ganz genau weiss das sich das NIE und nimmer ändern wird, und aus codetechnischen gründen es einfach angenehmer ist den kürzeren weg zu gehen.
reicht pointer auf partner
...

Auch wenn es nur Monogamie gäbe, könnte dieser Ansatz zu Problemen führen. Was ist, wenn das Programm plötzlich darüber Auskunft geben soll, welche Ehen in einem bestimmten Zeitraum geschlossen wurden?

vielleicht sollt ich einfach sagen:
der zweck heiligt die mittel
(vorausgesetzt man ist sich über den zweck im klaren)

hab eh auf seite 1 ein (überaus schlechtes *G*) beispiel des "richtigen" wegs geschrieben.

...

...
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 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

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* ).

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.

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.

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.

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;

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

LOL

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.

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

Btw "DPs" ?!?

design patterns