01.01.2026, 14:18
Hallo Thomas,
ich bin auch kein Freund, solche Diskussionen in einem Chat oder Forum zu führen – interaktiv kann man da besser abwägen, was die beste Option sein könnte.
Ich möchte lieber erst versuchen, die Abhängigkeit von PositionsModelImpl zum PositionHelper zu löschen. Es fühlt sich irgendwie falsch an, dass in einem Model Wissen über die Darstellung und Formatierung der Daten vorhanden ist. Was spricht dagegen, editCell() und getStringAt() herauszuziehen – und damit die Abhängigkeit von PositionsModelImpl auf PositionHelper zu lösen. Irgendwie haben ja auch die parseXXX() Methoden in einem Model wenig verloren und es würde die Idee des PositionsModelCallback weiter treiben.
Dann würde der von Dir geplante UnitTest gegen die Implementierung des Callbacks laufen. Damit wäre das PositionsModelImpl aus dem Spiel.
In einem zweiten Schritt könnte man dann in ParseHelper die Aufrufe wie RouteConverter.getInstance().getTimeZone() durch hineingereichte Models ersetzen, was Du ja bereits vorgeschlagen hast. Wenn ich mir den Code anschaue, dann sehe ich viele verteilte Codestellen, wo der PositionHelper aufgerufen wird. Es wäre wohl damit besser gewesen, ein kleines Dependency Injection Framework zu verwenden... ;-) Aber nicht alle Stellen brauchen die Abhängigkeit auf die hineingereichten Models sondern m.E. nur die, die aus editCell() und getStringAt() resultieren. Die könnte man aus RouteConverter-Klasse herauslösen (und es weniger zu einer Gottklasse machen könnte).
Konntest Du mir folgen?
ich bin auch kein Freund, solche Diskussionen in einem Chat oder Forum zu führen – interaktiv kann man da besser abwägen, was die beste Option sein könnte.
Ich möchte lieber erst versuchen, die Abhängigkeit von PositionsModelImpl zum PositionHelper zu löschen. Es fühlt sich irgendwie falsch an, dass in einem Model Wissen über die Darstellung und Formatierung der Daten vorhanden ist. Was spricht dagegen, editCell() und getStringAt() herauszuziehen – und damit die Abhängigkeit von PositionsModelImpl auf PositionHelper zu lösen. Irgendwie haben ja auch die parseXXX() Methoden in einem Model wenig verloren und es würde die Idee des PositionsModelCallback weiter treiben.
Dann würde der von Dir geplante UnitTest gegen die Implementierung des Callbacks laufen. Damit wäre das PositionsModelImpl aus dem Spiel.
In einem zweiten Schritt könnte man dann in ParseHelper die Aufrufe wie RouteConverter.getInstance().getTimeZone() durch hineingereichte Models ersetzen, was Du ja bereits vorgeschlagen hast. Wenn ich mir den Code anschaue, dann sehe ich viele verteilte Codestellen, wo der PositionHelper aufgerufen wird. Es wäre wohl damit besser gewesen, ein kleines Dependency Injection Framework zu verwenden... ;-) Aber nicht alle Stellen brauchen die Abhängigkeit auf die hineingereichten Models sondern m.E. nur die, die aus editCell() und getStringAt() resultieren. Die könnte man aus RouteConverter-Klasse herauslösen (und es weniger zu einer Gottklasse machen könnte).
Konntest Du mir folgen?
--
Christian
Christian