Objekte verheiratet - Wie am besten moddelieren ?

in Programmiersprache Objekte heiraten lassen? hahahaha das ist so lustig!

und wenn die einen Kind kriegen, wird die gene geerbt!

class Kind : public Tina, public Chris

hustbaer

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

inp

da lebensgemeinschaften eigentlich abstrakte konzepte einer gesellschaft sind (familien, eheverhältnisse, was auch immer), und nichts mit dem menschen im eigentlichen sinne zutun haben.
würd ichs auch als solches modellieren.

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

HumeSikkins

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

inp

HumeSikkins schrieb:

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.

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?

inp

multi gamer schrieb:

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.

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!