Ich denke das Problem ist eher ein Symptom dafür, dass die Klasse zu viele Verantwortlichkeiten hat.
Daten und Funktionalität zu trennen ist ein erster wichtiger Schritt.
Datenobjekte sollen nur die Datenstruktur abbilden aber keine fachliche Funktionalität enthalten.
Die gehört ins Model und das kann ebenfalls aus mehreren Unterklassen bestehn, die sich um einzelne Aufgaben kümmern.
Im Prinzip kann man jeden Anwendungsfall ähnlich aufbauen.
Dann findet man sich auch leichter zurecht, wenn mehrere Entwickler am selben Projekt arbeiten z.B.:
Code:
Model.Data .. Datenobjekt das alle Daten modeliert, mit denen gearbeitet wird (Unterobjekte, Listen)
Model.Repository .. Klasse zum Lesen und Speichern der Datenobjekten
Model.Config .. Enthält alle Einstellungen die mit Hilfe des Repository geladen oder gespeichert werden
Model.Provider .. stellt Schnittstellen zu anderen Anwendungsfällen bereit (z.B. Erlöskonten, Steuerarten ..), die Klasse wird dem Model beim Erzeugen mitgegeben
Model.Provider.Config .. falls die Einstellungen aus globalen Quellen stammen und nicht vom Model selbst geladen werden
Model.Params .. falls die Parameter nicht direkt an die Funktionen des Models übergeben werden, wird vom Model in der Schnittstelle veröffentlicht
So hat das Model nur noch Variablen für den aktullen Status und die braucht man nur vor dem Zugriff über die Schnittstelle zu schützen (readonly).
Man kann andere Strukturen für die Anwendung wählen, aber ohne Struktur werden große Anwendungen schnell unübersichtlich und kaum noch wartbar.