Softwaredesign in C++ im Vergleich zu Softwaredesign in Java/C#



  • softwaredesign schrieb:

    ich habe neulich ein Posting hier gelesen (leider ist mir der Link entfallen...), in dem gesagt wurde, dass sich der Softwareentwurf in C++ von dem in rein objektorientierten Sprachen wie C# (Java (fast rein objektorientiert)) unterscheiden würde.
    Solche Dinge wie Inversion of Control, tiefe Klassenhierarchien mit vielen abstrakten Klassen etc. wären eher in der Welt von C#/Java beheimatet.

    Solche Aussagen kommen meistens von C++ Fanboys wie volkard und Co. und ich glaube haben die wenigsten von denen haben schon an großen C++ Projekten gearbeitet.



  • in Java nennt man jede zweite Klasse XXXManager, in C++ eher nicht.



  • RAII statt Garbage Collection hat sich wohl durchgesetzt in C++.

    Ansonsten ist es stark davon abhängig, was man mit welchem Framework umsetzen will.
    Qt, wxWidgets etc. sind ebenfalls stark objektorientiert und von dieser Zeit geprägt.
    Auch müssen z.B. Eventsysteme in C++ nicht objektorientiert sein, man muss also nicht von MouseListener ableiten/diesen implementieren.



  • Die Sprache allein ist doch meist nicht so entscheiden. Viel wichtiger als Sprachfeatures sind die Frameworks/Libs die es für die Sprache gibt. Wenn sie dann noch gut mit Ressourcen umgehen kannst, hast du schon mal einen Volltreffen.

    Wer sich C++ aber nicht zu traut, der sollte einen oder zwei Gänge runter schalten und was einfaches machen. Muss ja nicht jeder in der Königsklasse mit spielen.



  • B4ndit schrieb:

    Wer sich C++ aber nicht zu traut, der sollte einen oder zwei Gänge runter schalten und was einfaches machen. Muss ja nicht jeder in der Königsklasse mit spielen.

    LOL. Die meisten spielen nur mit und sind nicht wirklich Königsklasse.



  • LOL C++ ist doch nicht die Königsklasse. Eher Haskell oder LISP.



  • Wie viel große oder wichtige Projekte sind denn in Haskell und LIPS aktuell am laufen im Vergleich zu C++?

    Klar spielen viele nur mit in der Königsklasse, mich eingeschlossen. Aber irgendwie muss man ja anfangen und manchmal reicht es schon aus nur ganz wenig C++ und Qt zu können um seine Projekte zum Abschluß zu bekommen. Man muss nicht jeden Datenbank zu Tode normalisieren und auch nicht jedes OOP-Projekt zu Tode designen und generalisieren.

    Ich hatte mal einen Kollegen, der hat alles bis zum Erbrechen generalisiert, damit ja alles erweiterbar und austauschbar ist. Das waren die schrecklichsten Monate in meinem IT-Leben die ich hatte. Wenn ein kleiner Ablauf auf zwanzig Klassen verteilt ist, ist das nicht mehr schön.

    Er selbst habe sich immer gewünscht pragmatischer an die Projekte rangehen zu können, so wie ein anderer Kollege. Dieser konnte auch mal schnell was in wenigen Stunden zusammen stricken was auch funktioniert hat. Die wenigsten Designs waren später gut erweiterbar, egal wie viel man am Softwaredesign geschraubt hat. Wenn viele Köche dort rumgerührt hatten, war es vorbei mit dem Durchblick und jeden kleine Änderung hat unglaublich viel Zeit benötigt. Da hat man sich schon mal eine Gott-Klasse gewünscht. Die hätten eine Menge Arbeitszeit gespart.

    Aber dies sind nur meine Erfahrungen.



  • Wie viel große oder wichtige Projekte sind denn in Haskell und LIPS aktuell am laufen im Vergleich zu C++?

    Das ist wohl kein geeignetes Mass. Ein PC-Spiel ist ja nicht automatisch schlecht, weil es kein Egoshooter ist.

    Ich hatte mal einen Kollegen, der hat alles bis zum Erbrechen generalisiert, damit ja alles erweiterbar und austauschbar ist. Das waren die schrecklichsten Monate in meinem IT-Leben die ich hatte. Wenn ein kleiner Ablauf auf zwanzig Klassen verteilt ist, ist das nicht mehr schön.

    Als ob das irgendwas mit dem Thema zu tun hat.

    Aber dies sind nur meine Erfahrungen.

    Nun, du hast wohl zu wenige gemacht. Vorzugsweise in anderen Programmiersprachen.

    dass sich der Softwareentwurf in C++ von dem in rein objektorientierten Sprachen wie C# (Java (fast rein objektorientiert)) unterscheiden würde.

    Ja, und zwar weil es unterschiedliche Sprachen sind, unterschiedliche Ausdrucksmittel bereitstellen und unterschiedliche Einsatzgebiete haben.



  • B4ndit schrieb:

    Das waren die schrecklichsten Monate in meinem IT-Leben die ich hatte. Wenn ein kleiner Ablauf auf zwanzig Klassen verteilt ist, ist das nicht mehr schön.

    Man zerlegt nicht für die Wiederverwendung, sondern um den Überblick zu behalten.



  • B4ndit schrieb:

    Ich hatte mal einen Kollegen, der hat alles bis zum Erbrechen generalisiert, damit ja alles erweiterbar und austauschbar ist. Das waren die schrecklichsten Monate in meinem IT-Leben die ich hatte. Wenn ein kleiner Ablauf auf zwanzig Klassen verteilt ist, ist das nicht mehr schön.

    Ich würde das so pauschal nicht sagen. Da gibts einfach sehr unterschiedliche Denkweisen. Es gibt Leute, die packen alles in eine Klasse mit sehr vielen sehr langen Funktionen und dann kommen halt 20 000 Zeilen Klassen raus, davon haben wir in der Arbeit genug, zum Glück nur Legacy Code, keine Neuentwicklungen. Und es gibt Leute, die sehen in jedem Algo erstmal das Template Pattern und brechen das auf zig Klassen auf, vielleicht mit Traits usw. Wenn man das gewohnt ist, kommt man damit auch gut zurecht. Ich bin eher für den Mittelweg, aber letzteres wäre mir immer noch lieber als ersteres.



  • Es ging da um ein kleines Frontend, wenn da jetzt eine hochkomplexe Software dahinter gewesen wäre, hätte ich dies noch verstanden, aber so! Naja, schön war auch noch die Tatsache, dass ein Framework genutzt wurde. Dieses wurde aber angepasst, weil Funktionalität fehlte. Am Ende konnte das Framework nicht mehr geupdatet werden, aber es konnte auch nicht komplett auf das neue Framework angepasst werden.

    Au man, das war der reinste Matsch aus den unterschiedlichsten Ansätzen und Framework-Versionen. Teilweise war was dokumentiert, aber ich saß auch zwei Wochen da und habe versucht mir mit meinem Notizblock einen Reim draus zu machen. Bis ich auch nur eine Checkbox ändern könnte, ist sehr viel Zeit und sind viele Nerven ins Land gegangen.



  • volkard schrieb:

    B4ndit schrieb:

    Das waren die schrecklichsten Monate in meinem IT-Leben die ich hatte. Wenn ein kleiner Ablauf auf zwanzig Klassen verteilt ist, ist das nicht mehr schön.

    Man zerlegt nicht für die Wiederverwendung, sondern um den Überblick zu behalten.

    Stroustrup würde dich ohrfeigen. 🤡 Ich bin sicher, ich finde ein paar Zitate, :kram-buch-raus:



  • Ich habe immer ein megamässig schlechtes Gewissen wenn einer meiner Klassen die 500 Zeilen Marke knackt. Lieber klein und fein.



  • volkard schrieb:

    B4ndit schrieb:

    Das waren die schrecklichsten Monate in meinem IT-Leben die ich hatte. Wenn ein kleiner Ablauf auf zwanzig Klassen verteilt ist, ist das nicht mehr schön.

    Man zerlegt nicht für die Wiederverwendung, sondern um den Überblick zu behalten.

    Sorry, an sich wirkst du ja fitt, aber es ist peinlich, was für einen Schwachsinn du manchmal für bare Münze verkaufst.
    Natürlich ist die Zerlegung eine ganz essentielle Methode, um Wiederverwendung zu erreichen.



  • Die Wiederwendbarkeit fällt aber nur als Abfallprodukt dabei raus.



  • Falsch!
    In C# ist es zum Beispiel üblich, gewisse Klassen aus den einzelnen Schichten einer Software herauszuziehen, um sie dann in einem WCF-Dienst auf beiden Seiten gemeinsam verwenden zu können. Das hat nichts mit Übersicht zu tun sondern man möchte schlicht erreichen, dass Änderungen an Klassen der Domäne sofort auf beiden Seiten der Kommunikation greifen.

    Das ist ein Beispiel von vielen.



  • Schon mal einen WCF-Dienst in C++ gesehen? Was gefaellt dir nicht an der Antwort:

    weil es unterschiedliche Sprachen sind, unterschiedliche Ausdrucksmittel bereitstellen und unterschiedliche Einsatzgebiete haben



  • jaaaanein schrieb:

    softwaredesign schrieb:

    ich habe neulich ein Posting hier gelesen (leider ist mir der Link entfallen...), in dem gesagt wurde, dass sich der Softwareentwurf in C++ von dem in rein objektorientierten Sprachen wie C# (Java (fast rein objektorientiert)) unterscheiden würde. ...

    ...und ich glaube haben die wenigsten von denen haben schon an großen C++ Projekten gearbeitet.

    Reichen dir berufliche Projekterfahrungen von über 10 Jahren in der C++ Entwicklung (plus etwas Erfahrung in den eben genannten anderen beiden Sprachen)?

    In C++ wird tatsächlich anders entwickelt. Es handelt sich um unterschiedliche Sprachen mit unterschiedlichen Möglichkeiten und Paradigmen. Der wesentlichste Unterschied ist das Sprachen wie C# und Java Reflection unterstützen, zudem basieren die grundlegenden Bibliotheken schon auf gänzlich anderen Prinzipien.

    Tiefe Klassenhierarchien sind nach meiner Ansicht aber in jeder Sprache ein Fehldesign (und machen Änderungen extrem schwer*). Komposition ist nicht selten eine bessere Alternative zu Aggregation.

    * Was inzwischen so jeder hier auf die harte Tour gelernt hat... (Wir haben an einer Stelle eine sehr tiefe Hierarchie, durch die Änderungen inzwischen fast unmöglich geworden sind; in Teilen habe ich die tiefe Hierarchie inzwischen durch mehrere flache Hierarchien ausgetauscht um überhaupt Änderungen vornehmen zu können).

    Zudem sind die C++ Templates wesentlich mächtiger als beispielsweise die C# Generics, und auch der fehlende GC wirkt sich auch auf die Art und Weise aus wie man in C++ entwickelt.

    Die Meinung zu IoC teile ich nicht, auch wenn ich glaube das IoC in der Form wie dies in C# und Java möglich ist, nur in bestimmten Grenzen machbar ist (u.a. wegen der fehlenden Reflection). Das heißt aber nicht das IoC gänzlich unmöglich wäre - selbst wenn ich dies in C++ Projekten noch nicht angetroffen habe (liegt vielleicht auch daran das die meisten C++ Projekte an denen ich bislang mitgearbeitet habe, ihren Ursprung im letzten Jahrhundert hatten).



  • softwaredesign schrieb:

    Natürlich ist die Zerlegung eine ganz essentielle Methode, um Wiederverwendung zu erreichen.

    Der gerne genannte Aspekt der Wiederverwendung hat sich in der Praxis als kaum umsetzbar herausgestellt (War ursprünglich einer der gerne genannten Hauptvorteile von OOP, heutzutage sind selbst reine Fachbuchautoren inzwischen teilweise bei der Praxis angelangt...).

    Ich habe nur ganz selten erlebt das man wirklich etwas Wiederverwerten konnte. Der Vorteil von OOP in der Praxis liegt fast ausschließlich in der Schaffung verständlicher kleiner Codeeinheiten. Die Wiederverwendung ist nur in seltenen Fällen gegeben (Da jeder Anwendungsfall in der Regel einen ganz anderen Detaillierungsgrad benötigt).



  • Kann ich nicht nachvollziehen. Ich sorge täglich für Wiederverwendbarkeit in meiner Arbeit.

    Zum Beispiel habe ich vor einigen Monaten eine Klasse geschrieben, welche gewisse Gruppendefinitionen aus einer beliebigen Datenquelle heraus ausliest, die den Gruppen zugewiesenen Entitäten analysiert und nach gewissen Kennzahlen, welche in der Gruppe stecken und hierarchisch verschmolzen werden müssen, modifiziert.

    Diese Erfordernis haben wir auf Basis verschiedener Datenquellen mit verschiedenen Kriterien.

    Was spricht nun dagegen, den Provider für die Datenquelle zu abstrahieren, ebenso das Auslesen und Bewerten der Kennzahlen?
    Diese Abhängigkeiten gebe ich eben der Klasse im Konstruktor mit.

    Und schon kann ich den Algorithmus überall verwenden.
    Sowas mache ich täglich, ist doch nichts besonderes? Welche Fachbuchautoren sollen das denn sein, welche die Wiederverwendbarkeit bezweifeln?


Anmelden zum Antworten