Weiterführende Frage zu "Datenbank Singleton blub"

[aaaaaaaaaüö]

Ich hab da mal weiter gemacht und es wurde Dependency Injection vorgeschlagen.
http://www.c-plusplus.net/forum/p2085458#2085458

[lin]

The Clean Code Talks - Global State and Singletons

[theta]

lin schrieb:

The Clean Code Talks - Global State and Singletons

Hab mir gerade den Talk angesehen - sehr interessant!

[Eisflamme]

Ja, find ich auch prima. Das Hauptproblem nach dem Video ist also das Testen.

Wieso gibt es für DI eigentlich kaum Frameworks für C++? Wird damit nicht so viel große Software geschrieben oder kann man das da einfacher lösen oder...? Wozu braucht man überhaupt ein Framework für die Aufgabe?

[hustbaer]

Wieso gibt es für DI eigentlich kaum Frameworks für C++?

Weil C++ keinen "object" Typ und keine Reflection hat.
DI ohne Framework kann man ja in C++ ohne weiteres machen.

Mit Framework funktioniert es aber meistens so, dass man in diversen Config-Files definiert welche Typen instanziert und über welche Setter an welche anderen Objekte übergeben werden sollen.

Dafür braucht man die beiden erwähnten Dinge: Reflection um die Klassen/Setter anhand ihres Namens ansprechen zu können. Und den "object" Typen, damit man mit Objekten beliebigen Typs arbeiten kann (=ohne dass diese von einer bestimmten Basisklasse abgeleitet sein müssen).

[Eisflamme]

Dann lässt man eben alles von einer Klasse erben. Nur, weil das in Java eingebaut ist, heißt das ja nicht, dass das in C++ schlechterer Stil ist, oder?

[hustbaer]

Eisflamme schrieb:

Dann lässt man eben alles von einer Klasse erben. Nur, weil das in Java eingebaut ist, heißt das ja nicht, dass das in C++ schlechterer Stil ist, oder?

Äh. OK. Damit hast du aber eine äusserst starke Abhängigkeit zum DI-Framework geschaffen. Das versucht man eigentlich zu vermeiden.

Und es löst nur eines der vielen Probleme.

Klar kann man auch für C++ ein DI-Framework basteln. Die Frage war aber warum es für C++ wenige DI-Frameworks gibt, nicht ob es theoretisch möglich ist.

Diese Frage habe ich versucht zu beantworten. Nochmal anders formuliert: Es gibt wenige C++ DI-Frameworks, weil es
* mehr Aufwand ist eines zu entwickeln
und
* mehr Aufwand ist eines zu verwenden

Zum zweiten Punkt: einerseits wird ein C++ DI-Framework vermutlich bestimmte Dinge nicht können (die Frameworks für andere Sprachen durchaus können), weil sich der Entwickler die Arbeit gespart hat, sie zu unterstützen. Alles lässt sich irgendwie machen, aber irgendwo muss man auch einen Schlussstrich ziehen, sonst wird man nie fertig.

Und andrerseits wird man als Anwender eines C++ DI-Frameworks vermutlich viel Glue-Code selbst schreiben müssen, was auch Aufwand ist. Man muss die Applikations-Klassen dem System ja irgendwie bekannt machen, inklusive der ganzen Setter/Getter/Verben die das DI-Framework ansprechen können muss. Und je mächtiger das DI-Framework ist, desto grösser wird der Aufwand vermutlich werden, die Klassen dem Framework bekannt zu machen.

Kurz gesagt: die Kosten-Nutzen-Rechnung sieht bei C++ einfach wesentlich schlechter aus, als bei einigen anderen Sprachen.

----

Noch ein Grund der dagegen spricht: es gibt Alternativen zu reinen C++ DI-Frameworks, die z.T. viel mehr können, und vermutlich auch nicht wesentlich aufwendiger zu verwenden sind.

Beispielsweise kann recht schön man mit Lua + CppLua/Luabind/Luabridge/... bzw. Python + SWIG/Boost.Python/... arbeiten.

Oder man kann die Applikation gleich in Java/C#/... entwickeln, und nur bestimmte Komponenten in C++ entwickeln (und diese dann über C++/CLI, Pinvoke, JNI oder was auch immer einbinden).

----

ps: fehlende Garbage-Collection ist ein Punkt den ich in meinem ersten Beitrag noch vergessen hatte. Das macht es auch nochmal komplizierter.

[Eisflamme]

Okay, jetzt hab ich's kapiert, vielen Dank.

Ist es denn ein großer Verlust, dass man solche Frameworks nicht nutzen kann/will? Ich meine, ist das ein Punkt, den man als gutes Argument gegen C++ einsetzen kann? Einige schwören ja auf DI und könnten das maßgeblich finden. Wobei man DI natürlich auch gut ohne Framework umsetzen kann.

[dot]

Ich verwend ständig DI und hab noch nie mit so einem Framework gearbeitet...

[hustbaer]

Eisflamme schrieb:

Ist es denn ein großer Verlust, dass man solche Frameworks nicht nutzen kann/will? Ich meine, ist das ein Punkt, den man als gutes Argument gegen C++ einsetzen kann?

Ich denke das kommt darauf an wen du fragst. Und um was für ein Projekt es sich handelt.
Bei vielen Projekten wird es egal sein.

Bei anderen Projekten würde es einiges an Arbeit sparen, wenn man ein praktikables DI-Framework hätte, mit dem man seine Applikation konfigurieren ("zusammenstecken") kann.
Hat man es nicht, muss man den Konfigurations-Code selbst schreiben.
Das führt dann manchmal zu seltsamen weil hausgebackenen Konfig-File-Formaten. Oder dazu dass man ein paar Abkürzungen nimmt, was sich negativ auf die Code-Qualität und/oder Flexibilität der Applikation auswirken kann.

Je nach Programm würde ich persönlich es als ein zusätzliches Argument gegen C++ sehen.