Java...
-
Michael E. schrieb:
std::adjacent_difference ist in <numeric> und nicht in <algorithm> definiert.
Ich weiss zwar gerade nicht auswendig, ob ausser ein paar numerischen Algorithmen noch was anderes in <numeric> ist, aber das ist ein weiteres Problem in C++. Die Standardlibrary ist total unuebersichtlich aufgeteilt. Numerische Algorithmen hat man willkuerlich in einen eigenen Header gesteckt, die Stdlib ist generell schlecht bis gar nicht gegliedert. Von Hierarchien brauch ich gar nicht erst anfangen.
Ich hoffe mal, dass sich da mit dem Modulsystem was tun wird. Ansonsten sehe ich schwarz fuer C++.
-
Was hat Dependency Injection mit der Sprache zu tun bzw. wie löst man etwas, dass man in Java mit DI macht in C++?
Die Frage wurde jetzt mindestens fünf Mal gestellt und keiner beantwortet sie, sondern umgeht sie einfach nur mit hohlen Phrasen wie "das braucht man in C++ nicht".
Das Einzige, was da bisher kam, war knivils Vorschlag die Schichten als Services zu implementieren. Wäre natürlich interessant, wie man dort die Messagequeue implementieren würde. Hat sonst niemand was?
Der Link zu DI bei Stackoverflow pointiert aber die Java-Vorteile nicht in den ersten Antworten. Die Antwort von Adam N (~50 Upvotes) erklärt es imo besser: http://stackoverflow.com/questions/130794/what-is-dependency-injection
Keine Ahnung. Java bietet sich für so Geschäftsanwendungen wahrscheinlich wirklich besser an, weil das Framework bereits da ist. Aber die Sprachmittel von C++ dürften etwas Vergleichbares wohl auch erlauben, aber das ist einfach nicht dafür gemacht? Trotzdem werden ja viele große Entwicklungen mit C++ gemacht, auch von Leuten, die was drauf haben und auch Java kennen. Und mit C++11 kommen viele Sprachmittel dazu, die im Unternehmensbereich ja noch gar nicht verbreitet sind. Hier muss sich erstmal das Wissen durchsetzen, dann kann es ganz neue Chancen geben. Für einen Boom in diversen Feldern wären neue Frameworks, die C++11 auch nutzen, vermutlich sehr förderlich.
Also ist es doch wohl auch für Architekturen gut zu gebrauchen, hat hier niemand andere Lösungen als DI für komplexe und flexible Verbindungen von Objekten zueinander?
-
ähh DI sind Policies? Das ist alles? Man kann auch alles kompliziert ausdrücken
-
Ich kann mit Policies nichts anfangen. Ich kenne von C++ nur policy-based-design und das hat damit nix zu tun...
-
asc schrieb:
Jester schrieb:
Verstehe, wir betrachten also Code, der *gleich gut* wartbar ist. Und unter all diesen gleich *gleich gut wartbaren* Codes ist dann der kürzere besser, weil er *besser wartbar* ist. Ja das klingt sinnvoll...
Nexus hat nicht "gleich gut wartbar" geschrieben, sondern Code der mehrere vergleichbare Kriterien erfüllt.
Ja, gut erkannt, aber jetzt weiter: Wenn ich das Kriterium "gut wartbar" hier nicht benutzen darf, weil dann unsinniger quatsch rauskommt, was heißt das? Ganz klar: kurzer Code geht im wesentlichen in Kriterien wie Korrektheit, Robustheit und Wartbarkeit auf. Es ist daher kein für sich stehendes Qualitätskriterium (anders als von nexus behauptet). Das hätte man aber natürlich auch einfach rausfinden können... http://de.wikipedia.org/wiki/Softwarequalität
-
Ich verstehe, was du meinst. Aber nach dieser Argumentation wären Lesbarkeit und Wartbarkeit auch keine orthogonale Qualitätskriterien, da letzteres stark von ersterem abhängt.
Ah, wie ich sehe, hast du das editiert
Aber es gilt weiterhin: Die Grenzen zwischen den Qualitätskriterien sind teilweise willkürlich gezogen. In deinem Standard überschneiden sich die einzelnen Kriterien (z.B. Modifizierbarkeit-Anpassbarkeit; Zuverlässigkeit-Richtigkeit).
-
otze schrieb:
ähh DI...?
Da sieht man realtiv gut, was man mit DI macht.
http://insidecoding.com/2012/02/03/guice-a-lightweight-di-framework-alternative-to-spring-part-1/
-
Eisflamme schrieb:
Keine Ahnung. Java bietet sich für so Geschäftsanwendungen wahrscheinlich wirklich besser an, weil das Framework bereits da ist. Aber die Sprachmittel von C++ dürften etwas Vergleichbares wohl auch erlauben, aber das ist einfach nicht dafür gemacht? Trotzdem werden ja viele große Entwicklungen mit C++ gemacht, auch von Leuten, die was drauf haben und auch Java kennen. Und mit C++11 kommen viele Sprachmittel dazu, die im Unternehmensbereich ja noch gar nicht verbreitet sind.
Ich arbeite als C++ Entwickler an einer großen Software, und ich hab eine ganze Weile mit Java und C# gearbeitet. Das ist aber keine "Geschäftssoftware", was wir schreiben, dafür würde ich tatsächlich auf jeden Fall Java oder C# nehmen (für Webanwendungen J2EE). Ich finde, das hat nichts mit Sprachmitteln zu tun. Große Teile von unserem Code sind tatsächlich auch einfach unsauber, einiges ist schon über 15 Jahre alt, vieles ist historisch bedingt gewachsen, ohne dass man Zeit für Refactoring fand usw... Ist aber egal, das ist halt eine typische große Real Life Software und viele neuere Module sind recht elegant, insgesamt kann ich gut damit leben. Was mich aber oft stört, sind "Klassen" (bzw. allgemein Funktionalität), die man nicht wiederverwenden kann. Ich denk mir oft, ich brauch irgendwas, sowas ähnliches haben wir doch schon irgendwo, schau mir an, wie das implementiert ist, und kanns dann nicht ohne weiteres wiederverwenden, weil die entsprechenden Klassen bestimmte andere Klassen verwenden, Config Dateien lesen oder sonstiges. Muss es dann meist umbauen und auf "DI" umstellen, in dem ich z.B. Konfigurationsparameter von außen reingebe, Schnittstellen extrahiere und als Strategieklassen reingebe usw. Das hat für mich nichts mit Sprachmitteln zu tun. Das Problem ist, dass viele beim Schreiben einer Klasse nur das konkrete Projekt vor Augen haben und nicht dran denken, das ganze auch etwas flexibler aufzubauen.
Aus meiner Sicht wird C++11 kaum etwas ändern, zumindest bei uns. Das ist ganz interessant für Bibliotheken, vielleicht auch für mathematische/physikalische Programme, aber in unserer eigentlichen Software seh ich erstmal nichts, wo wir irgendwelche C++11 Features brauchen würden.
-
Mechanics schrieb:
Was mich aber oft stört, sind "Klassen" (bzw. allgemein Funktionalität), die man nicht wiederverwenden kann. Ich denk mir oft, ich brauch irgendwas, sowas ähnliches haben wir doch schon irgendwo, schau mir an, wie das implementiert ist, und kanns dann nicht ohne weiteres wiederverwenden...
Anderen wirds mit deinem Code irgendwann auch so gehen. Man kann nie alles für alle richtig machen.
-
........--.. schrieb:
Mechanics schrieb:
Was mich aber oft stört, sind "Klassen" (bzw. allgemein Funktionalität), die man nicht wiederverwenden kann. Ich denk mir oft, ich brauch irgendwas, sowas ähnliches haben wir doch schon irgendwo, schau mir an, wie das implementiert ist, und kanns dann nicht ohne weiteres wiederverwenden...
Anderen wirds mit deinem Code irgendwann auch so gehen. Man kann nie alles für alle richtig machen.
Natürlich. Ist auch jetzt so, ich bau durchaus auch meinen eigenen Code um oder andere bauen meinen Code um. Es geht ja nur ums Prinzip DI vs. "nicht-DI" und was das mit der Programmiersprache zu tun hat.
-
Okay, aber das klingt für mich nach einer allgemeinen Schwäche des Codes, die weder etwas mit DI vs. non-DI noch C++ vs. Java zu tun hat. Wenn man Code gut schreibt, dann abstrahiert man Lösungen, sobald man erkennt, dass sie abstrahierbar sind. Und dann sind sie automatisch wiederverwendbar. Also kann man das genau so in Java wie in C++ implemenntieren.
-
Eisflamme schrieb:
Ich kann mit Policies nichts anfangen. Ich kenne von C++ nur policy-based-design und das hat damit nix zu tun...
doch. die misten Vorteile die bei DI angesprochen werden kann man auch analog mit PBD implementieren. Mocing geht zum Beispiel ganz toll. Ansonsten ist das Strategy Pattern auch als Policy bekannt.
Also merke ich mir: DI ist das Policy-Pattern mit XML Dateien um eine Ebene mehr Meta werden zu können. Da Policies aber seit jeher mithilfe von Factories verwaltet wurden...was ist nun an DI anders als an Policy? Kann mir das jemand aufdröseln? So mit einem UML Diagramm das genau herausstellt, wo der Unterschied liegt?
-
otze schrieb:
Eisflamme schrieb:
Ich kann mit Policies nichts anfangen. Ich kenne von C++ nur policy-based-design und das hat damit nix zu tun...
doch. die misten Vorteile die bei DI angesprochen werden kann man auch analog mit PBD implementieren. Mocing geht zum Beispiel ganz toll. Ansonsten ist das Strategy Pattern auch als Policy bekannt.
Also merke ich mir: DI ist das Policy-Pattern mit XML Dateien um eine Ebene mehr Meta werden zu können. Da Policies aber seit jeher mithilfe von Factories verwaltet wurden...was ist nun an DI anders als an Policy? Kann mir das jemand aufdröseln? So mit einem UML Diagramm das genau herausstellt, wo der Unterschied liegt?
Abhängigkeit vermeiden.
-
macht Strategy von Haus aus. Noch mehr?
-
Ne, deine Strategy kennt alle Implementierungen die es zurückgeben kann.
-
otze schrieb:
Also merke ich mir: DI ist das Policy-Pattern mit XML Dateien um eine Ebene mehr Meta werden zu können.
Das seh ich eben nicht so. Vielleicht wenn du von einem IoC Container sprichst. Aber der Begriff "DI" sagt noch gar nichts über XML Dateien oder zusätzliche Meta Ebenen. Auch Policies sind für mich eine Ausprägung der DI Idee. Das ist eben etwas was man beeinflußen, konfigurieren kann. Das ist Gegenteil davon, dass sich die Komponente die Daten selber, intern holt, ohne dass man es beeinflußen kann. Und das ist für mich viel entscheidender als die Frage, ob man das über über XML Dateien und einen IoC Container macht (was auch cool ist und was man sicher auch in C++ machen würde, wenn es möglich wäre), oder ob man das über Template Argumente zusammenfrickelt. Und wenn du dynamische Strategie-Policies verwendest (würde ich auch machen, würde man auch in Java machen), dann bist du in C++ erstmal genauso weit wie auch in Java. Keiner zwingt dich, die Abhängigkeiten automatisch reinzugeben, kannst auch manuell machen. Nur gibts bei Java noch grundsätzlich zusätzlich noch die Möglichkeit, das automatisch zu tun. Was aber wie gesagt nicht entscheidend ist.
-
Moment, PBD würde jede Klasse zum Template abwandeln. Für große Projekte geht dann doch die Compiletime in den Himmel. Finde ich nicht wirklich praktikabel anwendbar. Oder habe ich einen Denkfehler?
-
Eisflamme schrieb:
Oder habe ich einen Denkfehler?
Ja, ein bisschen schon. PBD ist das compile time Strategie Pattern. Das passt oft auch nicht. Habe ich selber z.B. ganz selten verwendet, aber es kommt auch auf den Code drauf an, den man schreibst. Nimm das richtige Strategie Pattern, das sind auch Policies, nur dynamisch. Hab ich schon sehr viel äfter verwendet, macht bei meinem Code sehr viel öfter Sinn.
-
Okay, also lässt sich das jetzt darauf zusammenfassen, dass man in C++ statt "meistens" das Strategy-Pattern verwendet, um gewisse Vorteile, die sonst DI mit sich brächte, zu erhalten: beispielsweise die Möglichkeit anzubieten für Tests Mock-Objekte reinzugeben. Also so was wie normale Parameterübergabe des zu injizierenden Objektes im ctor oder via Setter, aber eben basierend auf einem Interface, sodass es austauschbar ist.
Würdest Du in C++ irgendwas Spezielles machen, um schichtenübergreifend ganz viele Objekte gepackt an die nächste Schicht weiterzureichen? Beispielsweise irgendwelche Kontexte basteln (was - soweit ich das verstanden habe - ja einfach ne struct mit bestimmten Namen wäre?!)? Oder einfach ganz normal alle auflisten?