Also ich bin kein Spezialist in OOP, aber meine Vorstellung wäre folgende:
- Eine Klasse "Alarm", in der für jeden Alarm alle Attribute (Uhrzeit, Dauer, Anzahl Wiederholungen, Status usw...) hinterlegt sind und die entsprechenden Methoden, um all das zu verwalten. Für jeden Alarm gibts eine Instanz.
Die Attribute würde ich als JSON oder ähnlich abspeichern um sie ggf. wieder laden zu können. Auch die Methoden dafür gehören meiner Meinung nach in die Klasse.
- Ein Klasse "Alarmhandler", von der nur eine Instanz erzeugt wird und die alle Alarme managed. (Geht wahrscheinlich auch ganz ohne Instanz nur mit Klassenattributen.) Sollten hier überhaupt Settings nötig sein, würde ich hier ebenfalls Methoden hinterlegen, um die Daten zu speichern und zu laden.
Der Alarmhandler könnte die Klasse "Alarm" transparent verwalten, so dass gar kein direkter Zugriff vom (Haupt)Programm auf die Methoden von "Alarm" erfolgt.
- Eine Klasse "Audioausgabe", die die Methoden und ggf. Attribute für den Sound hat. Handling der Settings ebenso innerhalb der Klasse. Auch die Sound sollten dann vom Alarmhandler oder vielleicht noch besser vom Hauptprogramm aus gemanaged werden, nicht direkt von den Alarmen.
Ok, dann hat man drei mal Methoden für Dateizugriffe auf Attribute oder Objektdaten und der Einfachheit halber dann womöglich auch drei getrennte Settings-Dateien... Wenn man das unbedingt umgehen will, kann man auch eine Serttings-Klasse schreiben, die die Objekte in eine Datei schreibt und liest. Dann würde ich aber im Hauptprogramm ganz am Anfang alle Objekte aus der Datei lesen und in den jeweiligen Klassen instanziieren und nicht aus den einzelnen Klassen direkt auf die Settings-Klasse zugreifen. Ich bin der Ansicht, dass man Zugriffe von Methoden einer Klasse auf Methode/Attribute anderer Klassen möglichst vermeiden sollte. Im Zweifel lieber eine Funktion im Hauptprogramm erstellen, die zwischen beiden Klassen "vermittelt".
Wenn man aber persönlich mit kreuz und quer verlaufenden Zugriffen zwischen den Klassen leben kann, geht das natürlich auch. Ich finde aber, das ist sozusagen das OO-Pendant zum Spaghetti-Code.
Eine extra Klasse für die Settings erscheint mir nur dann sinnvoll, wenn diese Klasse sehr stabil und universell verwendbar ist. Die paar Zeilen Code in den einzelnen Klassen, die man für JSON braucht, machen das meiner Meinung nach nicht erforderlich.
Außerdem müssten die Programmteile, die neue Objekte (Alarme) erstellen oder Attribute ändern (auch beim Alarmhandler oder der Audioausgabe) dann auf die Settings-Klasse zugreifen und die Änderungen abspeichern. Im entsprechenden Programmteil müsste man also das Objekt erstellen/ändern und anschließend mittels Settings-Klasse die Änderungen speichern. Das ist doppelte Arbeit.
Wenn man die Methoden in den jeweiligen Klassen hat, kann man das bei Änderungen von Attributen oder Erstellung neuer Objekte transparent innerhalb der Klassen (Alarm, Alarmhandler, Audioausgabe) abarbeiten.
Den Zugriff aus den Klassen (Alarm, Alarmhandler, Audioausgabe) auf eine Klasse "Settings" würde ich wegen der intransparenten Abhängigkeiten jedenfalls vermeiden. Die Abhängigkeit von Alarm und Alarmhandler ist dagegen natürlich zwangsläufig - beide müssten in ein Modul gehören, das konsistent ist. Wenn man das auch noch umgehen möchte, kann man die relevanten Alarm-Attribute im Hauptprogramm an den Alarmhandler übergeben oder die Methoden des Alarmhandlers in die Klasse Alarm integrieren. Man kann ihnen beim Aufruf einzelne Alarm-Instanzen übergeben (was wiederholte Aufrufe bedingt), oder Listen von Alarm-Instanzen übergeben, z. B., um zu prüfen, ob einer der Alarmzeitpunkte erreicht ist (was ja wahrscheinlich jede Minute gemacht werden muss).
Das sollen nur ein paar Denkanstöße sein. Bitte fangt jetzt nicht an, zu zerpflücken, was da besser oder schlechter ist. Es gibt dutzende von möglichen Ansätzen und man kann sich bestimmt die Köpfe heiß reden... Welche man nimm, hängt am Ende wahrscheinlich vor allem von den Neigungen des Programmierers ab.