Design Pattern: Abwandlung von Observer

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
Fallen][Angel
User
Beiträge: 39
Registriert: Dienstag 20. Mai 2008, 12:38

Dienstag 23. Dezember 2008, 01:21

Moin,

ich hab gerade einen Gedanken im Kopf, wo ich an ein kleines Problemchen komme, wo ich euch mal fragen wollte, ob jemand eine Idee/Tipp hat.

Ich habe folgende Situation: Es existiert eine Instanz von Object A, welches einen Datensatz einer MySQL-Tabelle wiederspiegelt. Dieses Object besitzt z.B. einen Titel.

Dazu gibt es Object B, welches auch eine eigene MySQL-Tabelle darstellt, wo der Titel ebenfalls vorkommt. Nun nicht als Referenz, sondern (neben einer Referenz) auch als direkte Kopie.

Der Grund dafür ist, dass es vermieden werden soll, dass für eine Suche über Tabelle B erst diverse Joins aufgelöstet werden sollen und somit ein Plus für die Performance erzielt werden soll. An diesem Punkt kann ich leider nicht rütteln und muss ihn nun so hinnehmen.

"Problem" ist nun, dass wenn Objekt A seinen Titel geändert kriegt und gespeichert wird dann müsste ebenfalls auch der Titel bei Tabelle B geändert werden, da dieser ja eine direkte Kopie ist.

Wichtig bei dieser Situation ist nun: Es existiert zu diesem Zeitpunkt keine Instanz von Objekt B, welche dazu angesprochen werden könnte.

Ich dachte zuerst, dass es nach dem guten alten Observer Pattern aussieht, jedoch hab ich nun das lustige Problem, dass das übliche Observer Pattern davon ausgeht, dass Observer sowie Subject existieren.

Diesen Zustand kann ich nicht gewährleisten und wollte mir nun eine Logik dafür ausdenken, da ich nicht in Objekt A irgendwelche Logik reinpacken will, welche eigentlich zu Objekt B gehört.

Hatte zuerst daran gedacht, ob vielleicht drei Objekte nötig sind. Objekt A, Objekt B und praktisch der Observer. Wenn Objekt A ein Event auslöst, dann werden die nötigen Daten an den Observer übergeben. Der Observer kann jedoch nicht direkt Objekt B sein, da dieses ja nicht existiert. Somit müsste der Observer nun entsprechende Logik enthalten. Persönlich tue ich mich nun aber schwer, wenn der Observer nun eine Instanz von Objekt B erzeugen müsste, da ich ggf. befürchte, dass ich dadurch gewisse Freiheiten verliere und die Objekte zu stark binden muss.

Daher suche sich nun eine Idee und hoffe, dass ihr mir vielleicht helfen könntet. Dieses Beispiel ist absichtlich ohne jede Sprache, da die Umsetzung wohl nicht in Python passieren wird. Daher ist das Ganze etwas abstrakter ;)
BlackJack

Dienstag 23. Dezember 2008, 09:17

Man könnte es so implementieren, dass die Titeländerung dem Exemplar von B übermittelt wird, falls es existiert, oder ansonsten direkt in die Tabelle von B geschrieben wird.

Das Problem ist ein nettes Beispiel dafür warum solche Redundanzen wegnormalsiert werden sollten. Machen nur Ärger. :-)
Fallen][Angel
User
Beiträge: 39
Registriert: Dienstag 20. Mai 2008, 12:38

Dienstag 23. Dezember 2008, 09:48

BlackJack hat geschrieben:Man könnte es so implementieren, dass die Titeländerung dem Exemplar von B übermittelt wird, falls es existiert, oder ansonsten direkt in die Tabelle von B geschrieben wird.

Das Problem ist ein nettes Beispiel dafür warum solche Redundanzen wegnormalsiert werden sollten. Machen nur Ärger. :-)
Das Problem ist nur, dass ich an diesem Zustand nix ändern kann. An machen Stellen machen diese aber auch Sinn im System, bzw. ich kann diese verstehen. Ich hab nur das einfachste mal rausgepickt.

Es könnte genau so sein, dass ein Objekt aus mehreren weiteren Objekten besteht, welche alle einen Geldwert enthalten. Wenn ein Wert geändert wird, dann muss im "Hauptobjekt" eine Summe der Geldwerte aktualisiert werden.

Sowas würde dynamisch viel zuviel Rechenleistung fressen, wenn man es z.B. bei einer Auflistung aller "Hauptobjekte" machen müsste. Daher ist mein Beispiel mit dem Titel etwas schlecht gewählt.

Zum Thema: Die Chance, dass dieses Objekt existiert ist in aller Regel wohl zu gering. Somit würde ich immer direkt in die Datenbank von Tabelle B schreiben, was jedoch wenig OO wäre fände ich. Jedesmal aber ein Objekt initialisieren und dann einen Wert ändern und speichern find ich aber auch etwas heavy.
BlackJack

Dienstag 23. Dezember 2008, 10:28

Kennt die Datenbank `trigger`? Dann könntest Du das Problem vielleicht auch komplett aus dem Programm raushalten. Einfach bei Schreibzugriffen auf A-Datensätze per Trigger geänderte Titel in die andere Tabelle übertragen.
Fallen][Angel
User
Beiträge: 39
Registriert: Dienstag 20. Mai 2008, 12:38

Dienstag 23. Dezember 2008, 11:31

Eingesetzt wird im Moment "MySQL 5.1.11-beta", somit sollten Trigger eine Möglichkeit sein - stimmt! Hatte ich gar nicht daran gedacht.

Grundsätzlich würden sich damit einfachere Dinge erledigen lassen, etwas mehr Logik könnte ich auch noch mit if-Statements über MySQL direkt regeln lassen.

Sofern jedoch einmal mehr Logik oder auch ein Zugriff aufs Dateisystem nötig wäre, dann müsste ich dennoch für oben noch eine entsprechende Version haben. Oder sollten Trigger mal nicht möglich sein - wäre nun aus reinem Interesse, wie man das machen könnte :)
Antworten