Natürlich kann man zu allem immer ein Gegenbeispiel finden, wann es nicht klappt und doch besser anders sein soll. 20 Jahre Erfahrung sagen mir persönlich das man das diese Informationen zu Beginn oft nicht oder unvollständig hat und die Faustformel das zunächst maximal restriktiv zu handeln, die bessere ist.
Wie gesagt finde ich die es im Grunde Quatsch das jetzt mit irgendwelchen Eigenschaften eines realen Fahrrads zu begründen. Meine Idee für "reparien", in einem abstrakten Modell, wäre das alle reparierbaren Komponenten ein "Repairinterface" haben. Teil dieses Interface könnte enthalten, das man einen Vektor mit Subkomponenten mit Repairinterface holen kann, und dann nacheinander überall NeedsRepair() testet. Damit kannst du erstmal mit sehr generischem Code die konkrete Instanz finden, die repariert werden muss. Wenn zum Reparieren aber die Funkion Fahrrad.getReifen() nötig ist, dann sind damit plötzlich ganz viele solche Funktionen nötig, die irgendwo im Reperaturcode stehen müssen, damit der überhaupt an die kaputte Komponente kommt. Das hört sich sehr aufwendig und wartungsintensiv an und wäre für mich ein weiterer Grund, warum Fahrrad.getReifen() nicht existieren sollte.
