| 

.NET C# Java Javascript Exception

3
In einem Projekt sollen Planungen länderweise abgegeben werden.

In dem Objektmodell assoziiert demnach ein Planungsobjekt ein Landobjekt, welches aktuell nur einen Namen hat. Zusätzlich hält das Planungsobjekt den Namen des Landes redundant. Begründet wurde diese Designentscheidung wiefolgt: Man möchte die Information, für welches Land eine Planung abgegeben wurde, auch nach dem Löschen des Landes noch behalten.

Ist ein solches Vorgehen üblich oder sollte man von dem Vorgehen abraten?
News:
14.07.2011
oopexpert 455 1 8
Der Name des Landes wird im Planungsobjekt als String mitgeführt. Das Land-Objekt hat auch den Namen als String
oopexpert 14.07.2011
In unserem Projekt habe ich versucht die unterschiedlichen Semantiken klar darzustelllen. Diese wurden erkannt und wir führen nun ein ungueltig-flag ein. Dinge löschen zu wollen, obwohl ich die Information noch benötige ist tatsächlich objektoerientiert paradox. Deshalb nur ungültig und nicht deleted, was technisch gesehen ersteinmal nicht den großen unterschied macht.
oopexpert 15.07.2011
4 Antworten
1
Die redundante Haltung des Namens (ein String?) soll also die Lebensdauer eines Objekts, das irgendwann gelöscht werden kann, über seine Existenz hinaus verlängern? Das ist doch an sich schon paradox. Warum löscht man es dann?
Desweiteren (da kenn ich allerdings jetzt den Typ des Namens nicht, vermute aber mal gewagterweise string) müsste der Name dann auch eindeutig auf eine frühere Identität zurückschließen lassen, was aber aufgrund des gelöschten Objekts nicht mehr von der Applikation sondern nur noch vom Benutzer bewerkstelligt werden kann.
Statt den Namen redundnat zu halten, würde ich wie M.Fuchs schon vorschlägt, den Löschvorgang lediglich als "Scheinvorgang" implementieren und die Redundanz des Namens durch eine echte eindeutige Objektreferenz ersetzen.

EDIT - in Bezug auf Deinen Kommentar:
Aus objektorientierter Sicht würde ich wie folgt argumentieren:
Wenn nicht entscheidbar ist, dass eine der Klassen im Sinne einer Komposition die stärkere Rolle innehat, kann die Lebensdauer der schwächeren Assoziation auch nicht von der Stärkeren abhängen. Dann aber ist das Löschen eine fachliche Operation, die nicht direkt in objektorientierten Lebenszyklen abbildbar ist und daher nach einer anderen Konstruktion verlangt.

Gruß
Florian
14.07.2011
ffordermaier 8,4k 3 9
Was in meiner Fragestellung nicht genau rüberkommt ist, dass ich mich nicht am "Löschen" festhalten will. Insofern sehe ich genau das gleiche Paradoxon wie Du. Insofern ist es berechtigt zu fragen, ob die Semantik objektorientiert überhaupt das Löschen eines Landes zulässt.
oopexpert 14.07.2011
3
Es ist durchaus üblich aber unschön. Wenn Referenzen zwischen Objekt bestehen, dann sollte eines davon nicht einfach verschwinden. Bei relationalen Datenbank würde das ja auch zu Problemen führen.
Alternative: eine Eigenschaft namens "Deleted", die angibt dass das Land gelöscht wurde. Dann sollten durch das Programm neue Assoziationen nicht mehr möglich sein. Bestehende bleiben aber erhalten.
14.07.2011
m.fuchs 1,8k 2 8
Ich habe in einer Gruppendiskussion die unterschiedlichen Semantiken herausgestellt: Eigentlich ist der Wunsch da, Das Land doch irgendwie zu behalten, also darf es eigentlich nicht gelöscht werden. Es ist eigentlich zu unterscheiden zwischen gelöscht und nicht mehr neu assoziierbar.
oopexpert 14.07.2011
Es gibt eigentlich drei Möglichkeiten:
1. Land darf nicht gelöscht werden
2. Land wird logisch gelöscht (Deleted flag)
3. Land wird ungültig gesetzt (Ungueltig flag)
Wobei 2. und 3. sich nur semantisch unterscheiden.
oopexpert 14.07.2011
Je nachdem so gar noch mehr. Zum Beispiel ein Status "geschlossen" = keine neuen Projekte dürfen hinzugefügt werden, aber es werden bestehende bearbeitet. Letztendlich kann das alles recht komplex werden. Aber ich glaube klar ist auch: wirklich gelöscht darf das Objekt nicht werden.
m.fuchs 14.07.2011
Was bei uns oft zum Einsatz kommt sind Zeitscheiben.
Sprich das Land wäre von 01.01.2000 - 01.02.2000 gültig und kann in dieser Zeit assoziert werden wird danach aber nicht mehr überall angezeigt und kann auch nicht mehr assoziert werden.
Vorteil: Es gibt eine genaue Abgrenzung, die DS können auch wieder aktiv geschalten werden, In auswahllisten nicht sichtb.
Nachteil: Die Zeitscheiben-Logik führt bei Kunden oft zu Fehlkonfigurationen weswegen die Kunden öfter Support anfragen schicken, bei dennen sich eben meist herausstellt, das irgendein gültig bis oder von Datum nicht richtig gesetzt wird.
Voi 14.07.2011
1
Hallo,

die Redundanz bedeutet halt auch vermehrten Aufwand bei Aktualisieren, denn es müssen 2 Eigenschaften synchron gehalten werden. Wenn es normalisiert ist dann darf der Name auch nicht redundant enthalten sein - außer er ist der Fremdschlüssel.

Wenn in Abfragen oft nur der Name aus dem Landobjekt benötigt wird kann so vorgegangen werden - wie auch muffi schreibt.

Wenn jedoch ein Land sowieso nur zu einem Planungsobjekt gehören kann, dann würde ich - wie vorhin schon kurz erwähnt - den Namen als Fremdschlüssel verwenden und dann hast du die nötige Information und normalisiert ist es auch.

Edit: da du oben kommentiert hast dass es nur um das Objektmodell geht: dann halte ich das nicht für sinnvoll.

mfG Gü
14.07.2011
gfoidl 9,4k 3 5
gfoidl 9,4k 3 5
Die Planungsdaten überwiegen dimensional eklatant den Aufwand eines möglichen Tabellen-JOINs und der Abfrage-Frequenz eines Planungobjekt.
oopexpert 14.07.2011
0
So 100% sicher bin ich mir nicht, was Du meinst. Ich denke, Du hast in der Tabelle 1 einfach einen Fremdschlüssel, der als PrimärID in Tabelle2 steht. Falls dem so ist, mache ich das im Wesentlichen von der Performance abhängig. Benötige ich das redundante Feld sehr oft, halte ich die Spalte auch doppelt vor. Wenn man die Spalte so gut wie nie braucht, reicht es, das bei Bedarf mittels JOIN einzubinden.
14.07.2011
muffi 1,4k 1 9
Die Abbildung in einer relationalen Datenbank ist nicht gemeint, sondern die Repräsentation des Objektmodells. Üblicherweise unterscheiden sich die Sichten signifikant. DB-Tabellen sind sehr Technik-orientiert, während ein OO-Modell die Semantik stärker in den Vordergrund stellt.
oopexpert 14.07.2011

Stelle deine Loeschen-Frage jetzt!