Mehrere Objekte schreiben Daten: So vermeiden Sie dies
Sie kennen diese Zeiten, wenn Sie an einem Programm arbeiten, und es gibt einige Stellen in Ihrem Code, die abhängig von den Anforderungen oder einem sich irgendwie manifestierenden Fehler direkt damit zusammenhängen, dass Sie mehrere Objekte haben, die Daten schreiben zum selben Datenspeicher? Das ist nicht gut.
Das ist eine schreckliche Art, einen Beitrag zu beginnen. Lassen Sie mich das noch einmal versuchen.
Mehrere Objekte schreiben Daten
Angenommen, Sie arbeiten an einem Programm, und der Code aktualisiert unter anderem einen Zähler irgendwo in der Datenbank, um zu verfolgen, wie viele Änderungen in einem kurzen Zeitraum vorgenommen wurden.
Das Problem: Sie haben mehrere Stellen im Code, die diesen Zähler aktualisieren.
Mehrere Objekte schreiben Daten (falls meine Handschrift so unleserlich ist, wie es scheint).
Ich glaube nicht, dass viele von uns sich vorgenommen haben, solchen Code zu schreiben, aber es passiert, und wenn es passiert, hat es am Ende all diese Nebenwirkungen, die nur alle Arten von abgefahrenem Verhalten hervorbringen. (Ich kenne den offiziellen, akademischen Begriff dafür nicht – und ich meine nicht DRY – aber ich bin mit „funky Behaviour” für diesen Beitrag einverstanden.)
Wir wissen intuitiv, dass wir einen einzigen Ort haben sollten, an dem all dies geschieht, externe Faktoren – sei es ein Scope Creep, ein Missverständnis unsererseits, um die Anforderungen zu verstehen, oder was auch immer – führen zu einer schlechten Codierung.
Dann haben wir also all diese Entitäten in unserem System, von denen jede mit einem einzigen Punkt in unserer Datenbank (oder einem beliebigen Datenspeicher) kommuniziert, aber keine von ihnen weiß, dass andere mit ihnen sprechen.
Grenzen einrichten
Wir können versuchen, dies mit Bedingungen und dergleichen zu bekämpfen, aber wir machen es nur noch schlimmer. Was sollen wir also tun?
Ich weiß, wie bei vielen Dingen in der Programmierung gibt es eine Vielzahl von Möglichkeiten, dies zu lösen, aber vielleicht besteht einer der ersten Durchgänge des Refactorings darin, eine Klasse zu haben, die für die Ausgabe von Updates an den Datenspeicher verantwortlich ist.
Auf diese Weise können wir von der obigen Abbildung zu etwa folgendem übergehen:
Mehrere Objekte schreiben Daten: Senden Sie sie an eine Art Mediator.
Das heißt, alle Entitäten, die mit diesem Objekt und diesem Objekt gemeinschaftlich sind – und nur dieses Objekt kann Daten in die Datenbank lesen und schreiben.
Es gibt ein paar Designmuster, die zu diesem speziellen Problem passen würden, aber das würde den Rahmen dieses Beitrags sprengen. Stattdessen möchte ich darauf hinweisen, dass, wenn Sie sich mit einem Problem konfrontiert sehen:
- Entitäten schreiben Daten in den Datenspeicher,
- Mehrere Entitäten tun es,
- Und es züchtet unbeabsichtigte Konsequenzen,
Versuchen Sie dann, eine Klasse oder eine Reihe von Klassen zu erstellen, die ausschließlich für das Lesen und Schreiben von Daten verantwortlich sind. Lassen Sie die Informationen nur durch diese Klassen passieren, anstatt dass mehrere Klassen die Datenbearbeitung vornehmen.
Es erleichtert das Testen, das Debuggen und letztendlich das Lesen.