Diese hierarchische Konvention dient der Klarheit und hilft uns, den Einflussbereich der einzelnen Einstellungen zu kennen und mehrere Einstellungen mit identischem oder mehrdeutigem Namen zwischen verschiedenen Modulen zu unterscheiden.
Dies ist nützlich in Anwendungen mit zu vielen möglichen Einstellungen, um sie in die Hauptbenutzeroptionsseiten aufzunehmen (auf denen die Hierarchie durch Registerkarten oder Seiten angezeigt wird). Dies ist eine gute Alternative zu einfachen INI-Dateien (mit [title]
Abschnittsbegrenzern), die anfälliger für Benutzerfehler sind und erfordern in der Regel einen Neustart der Anwendung, um wirksam zu werden.
Hierarchische Einstellungen spiegeln wahrscheinlich auch das interne objektorientierte Top-Down -Modell wider, das von den Entwicklern verwendet wird:
In diesem Beispielmodell können wir uns sehr gut vorstellen, dass dort eine person.professor.disallow_strikes = true -Einstellung vorhanden ist, während ein students.disallow_strikes auf false stehen kann oder überhaupt nicht verfügbar ist. Diese Unterteilung ist auch die Grundlage für Namespaces in Programmiersprachen (und das gängige .NET-Framework folgt genau derselben Namenskonvention:) using System.Threading.Tasks
.
Wir können also jetzt davon ausgehen, dass die network.http.xxx
Einstellung keinen Einfluss auf network.ftp
oder auf andere Netzwerk-Submodule haben sollte, während eine network.xxx
Einstellung wahrscheinlich alle beeinflusst.
Die zusätzlichen Informationen sind von Vorteil ...
für den Benutzer: Wir haben eine bessere Vorstellung davon, auf welchen Teil der Anwendung eine bestimmte Einstellung Einfluss hat, wodurch Probleme leichter zu beheben sind (und vermieden werden können).
und für die Entwickler: Die Person, die an einem bestimmten Modul arbeitet oder Fehlerbehebungen vornimmt, kann leicht erkennen, welche vom Benutzer veränderbaren Einstellungen die aktuelle Arbeit beeinflussen und sich darauf konzentrieren können.