BASIC - Refactoring #85

New issue

Closed

opened 2026-04-02 15:38:05 +02:00 by thomasknaus · 0 comments

thomasknaus commented

2026-04-02 15:38:05 +02:00

(Migrated from github.com)

Harte Koppelung bei Predictor-Klassen auflösen (Dependency Injection nutzen)
Im DataProcessor instantiated ihr über dutzende Zeilen alle Predictoren selbst (z. B. private val fuelTrendPredictor = FuelTrendPredictor()). Vorschlag: Da das Projekt ohnehin Koin als DI-Framwork nutzt (sichtbar in AppModule.kt), können wir diese "Predictors" in den Koin-Graphen heben. Im DataProcessor lassen wir sie uns via Constructor Injecton (oder als Liste List) übergeben. Das macht den Code besser testbar (Mocking).
3. Open-Closed-Principle bei der CommandFactory
Die CommandFactory wertet die Sprachkommandos aus der commands.json aus. Zur Generierung der Strings gibt es dort intern einen gigantischen when (id)-Block (getResponseProvider). Für jedes neue Sprachkommando in der JSON müsst ihr den Code der CommandFactory verändern. Vorschlag: Einführung des Strategy Patterns. Wir können ein Interface CommandResponseHandler erstellen. Jeder Spezifische Handler (z. B. GapFrontHandler, PitStrategyHandler) implementiert dieses Interface und registriert sich selbst für sein id. Die Factory sucht dann einfach in zu Laufzeit nach dem passenden Handler.
4. "Magic Numbers" konsolidieren
Sehr oft finden sich harte Berechnungszahlen direkt im Code verstreut, z.B. rawErs / 4000000f, Arrays der Länge (FloatArray(10)) für Lärm/Lenkungs-Berechnungen oder Magic Strings bei den Rules. Vorschlag: Wir können ein Objekt RaceConstants anlegen, um diese Magic Numbers und Annahmen an einem zentralen Ort einstell- und dokumentierbar zu machen.

Harte Koppelung bei Predictor-Klassen auflösen (Dependency Injection nutzen) Im DataProcessor instantiated ihr über dutzende Zeilen alle Predictoren selbst (z. B. private val fuelTrendPredictor = FuelTrendPredictor()). Vorschlag: Da das Projekt ohnehin Koin als DI-Framwork nutzt (sichtbar in AppModule.kt), können wir diese "Predictors" in den Koin-Graphen heben. Im DataProcessor lassen wir sie uns via Constructor Injecton (oder als Liste List<RaceDataPredictor>) übergeben. Das macht den Code besser testbar (Mocking). 3. Open-Closed-Principle bei der CommandFactory Die CommandFactory wertet die Sprachkommandos aus der commands.json aus. Zur Generierung der Strings gibt es dort intern einen gigantischen when (id)-Block (getResponseProvider). Für jedes neue Sprachkommando in der JSON müsst ihr den Code der CommandFactory verändern. Vorschlag: Einführung des Strategy Patterns. Wir können ein Interface CommandResponseHandler erstellen. Jeder Spezifische Handler (z. B. GapFrontHandler, PitStrategyHandler) implementiert dieses Interface und registriert sich selbst für sein id. Die Factory sucht dann einfach in zu Laufzeit nach dem passenden Handler. 4. "Magic Numbers" konsolidieren Sehr oft finden sich harte Berechnungszahlen direkt im Code verstreut, z.B. rawErs / 4000000f, Arrays der Länge (FloatArray(10)) für Lärm/Lenkungs-Berechnungen oder Magic Strings bei den Rules. Vorschlag: Wir können ein Objekt RaceConstants anlegen, um diese Magic Numbers und Annahmen an einem zentralen Ort einstell- und dokumentierbar zu machen.