Welche Entwurfsmuster können auf das Problem mit den Konfigurationseinstellungen angewendet werden?

82

Bei großen und komplexen Softwareprodukten wird die Verwaltung konfigurierbarer Einstellungen zu einem großen Problem. Zwei Ansätze, die ich für das Problem gesehen habe, sind:

  • Lassen Sie jede Komponente im System ihre eigene Konfiguration aus Konfigurationsdateien oder Registrierungseinstellungen laden.
  • Haben Sie eine Settings Loader-Klasse, die alle konfigurierbaren Systemeinstellungen lädt, und lassen Sie jede Komponente den Settings Loader nach ihren Einstellungen abfragen.

Diese Ansätze fühlen sich für mich beide falsch an.

Gibt es Entwurfsmuster, die zur Vereinfachung des Problems verwendet werden könnten? Vielleicht etwas, das die Abhängigkeitsinjektionstechnik ausnutzen würde.

design-patterns  configuration  configuration-files  application-settings 
— paxos1977
quelle
4
Warum denkst du, ist Option 2 falsch?
— ChaosPandion
2
Es wird normalerweise als Singleton implementiert, es gibt jedoch auch andere Möglichkeiten, es zu implementieren.
— Daniel Bingham

Antworten:

47

Ich bevorzuge es, eine Schnittstelle zum Festlegen von Abfragen, Laden und Speichern zu erstellen. Durch die Verwendung der Abhängigkeitsinjektion kann ich diese in jede Komponente injizieren, die dies erfordert.

Dies ermöglicht Flexibilität beim Ersetzen der Konfigurationsstrategie und bietet eine gemeinsame Basis für alles, worauf es ankommt. Ich ziehe dies einem einzelnen globalen "Einstellungslader" vor (Ihre Option 2), insbesondere da ich den Konfigurationsmechanismus für eine einzelne Komponente überschreiben kann, wenn ich dies unbedingt tun muss.

— Reed Copsey
quelle
7
hallo, es wird schön sein, wenn du ein Beispiel
— teilst
20

Ich arbeite derzeit auf einem System, auf dem die Konfiguration von einem globalen Singleton-Objekt verwaltet wird, das eine Zuordnung von Konfigurationsschlüsseln zu Werten enthält. Im Allgemeinen wünschte ich mir, es wäre nicht so gemacht worden, weil es zu Parallelitätsengpässen im System führen kann und für Unit-Tests usw. schlampig ist.

Ich denke, Reed Copsey hat das Recht dazu (ich habe ihn gewählt), aber ich würde definitiv empfehlen, Martin Fowlers großartigen Artikel über Abhängigkeitsinjektion zu lesen:

http://martinfowler.com/articles/injection.html

Ein kleiner Nachtrag auch ... Wenn Sie einen Mock-Objekttyp-Unit-Test durchführen möchten, ist die Abhängigkeitsinjektion definitiv der richtige Weg.

— Brent schreibt Code
quelle
Es scheint, dass der Dekorateur Ihren Bedürfnissen entspricht. Sie können einen serialisierbaren Dekorator erstellen, mit dem Klassen auf ihre eigene Weise serialisierbar gemacht werden können. Mit der Strategie können alle Objekte ihre Strategie für die Serialisierung festlegen. Objekte, die nicht serialisiert werden müssen, können die Ignorierstrategie verwenden. Diejenigen, die nur ihre Felder serialisieren müssen OnlyFields-Strategie und so weiter. Sie sind ll be flexible with adding new things to your config. Sure as all approaches this have itVor- und Nachteile.
— Jaroslaw Jakowlew
4

Wie wäre es damit. Sie definieren eine Schnittstelle, die mit einer einzigen Methode konfiguriert werden kann. Konfigurieren (Konfiguration). Das Konfigurationsargument ist einfach eine Hashtabelle, die die Namen der Konfigurationsparameter mit ihren Werten verknüpft.

Root-Objekte können eine Konfigurations-Hashtabelle nach Belieben erstellen (z. B. Lesen aus einer Konfigurationsdatei). Diese Hashtabelle kann Konfigurationsparameter für das Stammobjekt iselft sowie alle Parameter enthalten, die eine ihrer Komponenten, Unterkomponenten, Unterunterkomponenten (usw.) möglicherweise verwendet.

Das Root-Objekt ruft dann configure (configuration) für alle konfigurierbaren Komponenten auf.

— Alain Désilets
quelle
0

Sie können mehrere Implementierungen einer Schnittstelle erstellen, die den Konfigurationslader definiert. Grundsätzlich Strategiemuster, bei dem Sie eine grundlegende Schnittstelle als configLoader und anschließend weitere verschiedene Implementierungen wie FileSystemLoader, ClasspathLoader, EnvVariablesLoader usw. definieren können. Details unter diesem Link

— HS Raju
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.