Weiterführende Frage zu "Datenbank Singleton blub"
-
Hi,
volkard hat ja leider den Thread geschlossen, ich habe ihn passiv die ganze Zeit verfolgt und bin jetzt auch Fan davon weniger Singletons zu verwenden (wobei ich die ja sowieso kaum nutze).
Gibt es solche Diskussionen eigentlich auch von irgendwelchen Informatik-Gurus in Büchern ausgeführt? Ich meine, damit haben sich sicher einige Leute Jahrzehnte beschäftigt, die werden ihr Wissen doch wohl auch weitergegeben haben. Kann man mir dazu Bücher empfehlen?
Also im Detail ginge es mir um die Anwendung von Design Patterns oder auch nicht. Bücher wie Gang of Four stellen ja einfach alle dar und schmeißen damit um sich, richtig? Und das Zweite, was mir an den GoF-Büchern nicht unbedingt liegt, ist, dass die eher auf Java ausgerichtet sind, oder? Das Observer-Pattern wird da ja großzügig mit Klassen implementiert, wohingegen Möglichkeiten wie in C++ über signals vernachlässigt werden, soweit ich weiß.
Oder gibt es gar eine Seite, wo man zu solchen Diskussionen viele interessante Artikel findet? Ich trachte nach Material und Infos. ^^
Vielen Dank auch an dot schon Mal für die vielen hilfreichen Anregungen!
-
Klick mich. Eine Diskurs zum Thema von Meyers und Alexandrescu
-
Ich hab da mal weiter gemacht und es wurde Dependency Injection vorgeschlagen.
http://www.c-plusplus.net/forum/p2085458#2085458
-
-
lin schrieb:
Hab mir gerade den Talk angesehen - sehr interessant!
-
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?
-
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).
-
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?
-
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 verwendenZum 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.
-
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.
-
Ich verwend ständig DI und hab noch nie mit so einem Framework gearbeitet...
-
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.
