UML-Darstellung gesucht

über ein XOR-Constraint

Hallo Claudio,

danke für den Begriff - kaum weiß man nach was man suchen soll schon 
findet man es auch :-)

Viele Grüße

Bitte. Normalerweise braucht man so etwas aber nicht, wenn du willst und 
darfst, dann kannst du ja mal die ganze Fachlichkeit hier bereitstellen, 
vielleicht fällt dann jemand eine andere Lösung ein.

Übrigens brennt mir auch immer folgender Tip auf der Seele: "Möglichst 
selten eine Aggregation benutzen". Eine Aggregation hat nämlich keinen 
wirklichen semantischen Unterschied (den man in der Implementierung 
sieht)  zur Assoziation, und die Leute können dann eine Stunde lang 
diskutieren, ob das wirklich eine Aggregation ist. Meine Modelle kommen 
alle ohne Aggregation aus. Entweder Komposition oder Assoziation, das 
genügt mir.

Claudio H. schrieb:
> Normalerweise braucht man so etwas aber nicht, wenn du willst und
> darfst, dann kannst du ja mal die ganze Fachlichkeit hier bereitstellen,
> vielleicht fällt dann jemand eine andere Lösung ein.
Ich könnte das Ganze auch anders lösen, aber dann habe ich noch eine 
Klasse mehr.
Sähe dann so aus, dass Class1 und Class2 von einer gemeinsamen 
Basisklasse erben (Class12) und Klasse A nur noch einen Pointer auf 
Class12 hat...
Aber einen wirklichen Vorteil kann ich darin jetzt auch nicht erkennen. 
Deswegen eben die Frage wie ich das 'entweder oder' in UML darstellen 
kann.

Claudio H. schrieb:
> Eine Aggregation hat nämlich keinen
> wirklichen semantischen Unterschied zu Assoziation, und die Leute können
> dann eine Stunde lang diskutieren, ob das wirklich eine Aggregation ist.
Bisher ist diese Diskussion nicht aufgekommen. Und wenn doch kann man 
sich immer noch über die Darstellung unterhalten. Glaube auch nicht, 
dass so viele Leute den Unterschied tatsächlich bemerken...

Danke nochmal und viele Grüße

>Aber einen wirklichen Vorteil kann ich darin jetzt auch nicht erkennen.

Der wird dann erkennbar, wenn du zu Class1 und Class2 noch Class3 
hinzufügst. Dann musst du in deinem Fall nämlich auch A ändern, im 
anderen Fall nicht. Und bei jedem Zugriff bei dir muss geprüft werden, 
ob auf Class1 oder Class2 zugegriffen werden soll.

Ich würde den Code von Anfang an auf Erweiterbarkeit auslegen, das 
macht sich meistens im Nachhinein bezahlt. Aber es funktionieren 
natürlich beide Ansätze...

Ich muss da Claudio zustimmen.

So "geht" es auch ist aber hochgradig umständlich. Gibt es Geld für 
eingesparte Klassen/Interfaces? Wenn du eine abstrakte Basisklasse nutzt 
kannst du sogar Funktionalität welche sich Klasse 1+2 teilen auslagern 
und hast hier jedenfalls pflegbaren Code! Später wirst du dich sonst nur 
immer mehr in Fallunterscheidungen und Spezialfällen in Klasse A 
verheddern.

Na gut, Ihr habt mich 'überzeugt'. Ich stimme Euch zu, dass es auf lange 
Sicht wohl günstiger ist das doch über eine Basisklasse zu handeln.

Danke fürs Augen öffnen und viele Grüße