Guter Talk (auch wenn zwischendurch die Codebeispiele nicht ganz aktuell gehalten waren ^^). Aber gerade den Punkt mit dem Open/Close-Principle fand ich sehr interessant.
Das stimme ich zu.
Leider zeigt er aber auch, dass die methode nicht zwangsläuft gegen „overengeneering“ hilft, denn den selben Effect hätte man auch gehabt, wenn man einfach eine Liste von Strings genommen hätte, statt das Rule-Interface einzuführen.
(und dabei behauptet man doch immer, nur wir Java-Entwickler bauen für alles ein Interface und eine Factory…)
bye
TT
Fand ich jetzt nicht schlimm. Letztendlich ging es ja darum das Open/Close-Principle zu verdeutlichen und bei so einem Fall könnte es durchaus sein, dass man hier und da doch mal mehr Logik braucht.
Hat mich auch inspiriert nochmal ein Game-of-Life anzufangen mit dem TDD-Weg von Ihr. Denn ich hab bisher eigentlich mehr Happy-Path-Testing betrieben. Ist auf jeden Fall interessant mal mit so starkem Focus zu programmieren wie Sie es tut.
Nun ja, C#ler haben halt noch eine recht gute Ausrede für viele Interfaces: Mocking. Ich habs mir auch angewöhnt, weil afair Klassen nicht (oder nur mit viel Aufwand) mockbar sind.
[quote=„Tomate_Salat, post:4, topic:21296“]
Fand ich jetzt nicht schlimm.
[/quote] Ich schon, denn es Widerspricht ihrem Punkt aus der Einführung: stay focussed.
Und damit fällst Du in das YAGNI-Antipattern…
Komplexität, die nicht durch UTs gefordert wird ist schlicht zu vermeiden.
bye
TT