Fragen? Antworten! Siehe auch: Alternativlos
Häufig genannte Argumente pro Inversion of Control sind, dass man so bessere Unit-Tests machen kann. Hey, was soll ich euch sagen, das konnte ich in C++ auch immer ohne neue Indirektionsschichten. Das Argument kann ich nicht gelten lassen.
Ich verdiene mein Geld damit, anderer Leute Quellcode zu lesen. Der beste Code ist der, den kurz aber selbstverständlich ist. Code, bei dem man irgendwo nachschlagen muss, um zu sehen, dass er korrekt ist, ist schlechter Code. Code, bei dem nicht mal der Compiler erkennen kann, wer da eigentlich gerade aufgerufen wird, ist die Steigerung von schlechtem Code. Nicht nur, weil man einen riesigen Kontext braucht, um ihn lesen zu können, und damit um bestimmte häufige Fehlerklassen ausschließen zu können. Sondern auch weil der Compiler nicht inlinen kann, wenn die Interfaces alle dynamisch zusammengepfropft werden. Bei Java heißt es immer, der JIT-Compiler könnte das dann schon fummeln, aber guckt euch doch mal das Laufzeitverhalten von typischen Java-Anwendungen an! Sieht das für irgendjemanden so aus, als könne der JIT da irgendwas signifikantes rausoptimieren? Oder überhaupt optimieren?
Ich höre auch häufig als Argument, dass man mit Java so produktiv sein kann, dass man so schnell Projekte stemmen kann. Auch das kann ich nicht aus der Praxis bestätigen, im Gegenteil. Was in Java tatsächlich gut geht ist das Parallelisieren von großen Projekten. Weil sich die Java-Leute eben erstmal auf Interfaces einigen und die dann runterimplementieren. Das könnte man auch in anderen Sprachen machen, aber es macht keiner. Nicht weil es nicht ginge, sondern weil man am Anfang des Projektes noch gar nicht sagen kann, was man konkret für Interfaces brauchen wird, und wie die genau aussehen müssen. Das ist m.E. auch der Hauptgrund für diese ganzen Fummel-Patterns wie Interceptor und Proxy. Das Projekt wird zwar schneller "fertig", aber dann hat man eben den Mehraufwand, um die ganzen Teile zusammenzukleben.
Das ist auch bei C++ eines der Hauptprobleme beim Software Engineering, dass die Leute alle glauben, ihr Kram müsse wiederverwendbar sein. Und dann entsteht eben statt der Klasse mit den 8 benötigten Methoden die "generische" Klase mit den 23 Methoden, von denen nur 8 überhaupt jemals aufgerufen werden und der Rest kompiliert womöglich nur deshalb, weil es Templates sind, die nirgendwo instanziiert werden, und die fliegen einem dann bei der ersten Instanziierung um die Ohren. Und der erste, der das tatsächlich wiederverwerten will, der hat am Ende mehr Aufwand, als wenn er die 8-Methoden-Klasse bedarfsgerecht erweitert hätte.
Übrigens: hier gehen tatsächlich ein paar Mails und Tweets von Studenten ein, die mir vorwerfen, ich habe von Software-Engineering keine Ahnung. Nein, wirklich! Leute, die noch nie irgendwo eine Zeile echten Code geschrieben haben, die sich ihren Boilerplate von der IDE generieren lassen und ohne Eclipse-Plugins zum Webservice-XML-Definitions-Export nicht arbeiten können, solche Leute werfen mir vor, ich habe keine Ahnung von Software-Engineering. Köstlich! Gut, dass das Internet nicht vergisst. Das wird sicher lustig, wenn ihr euch das erste Mal irgendwo zu bewerben versucht, Jungs. Oh und googelt mal den Dunning-Kruger-Effekt.