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



  • 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?



  • softwaredesign schrieb:

    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?

    Du darfst dich nochmal melden wenn du diese Komponenten wirklich irgendwo wiederverwendet hast. Kann interessiert keinen.



  • Ja habe ich. Und das mache ich in vielen Bereichen.
    Im Prinzip ist das doch nichts anderes, was auch viele Frameworks tun und auch in einigen Design Patterns beschrieben wird (zB Builder).
    Gemeinsame Schnittmenge von Funktionalitäten identifizieren, Besonderheiten abstrahieren und auslagern.

    Ich verstehe nicht, warum das etwas besonderes ist. Ich kenne das auch aus der täglichen Arbeit meiner Kollegen.



  • softwaredesign schrieb:

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

    Manches lässt sich Wiederverwenden, aber nach meiner Erfahrung ist dies insgesamt der kleinste Teil. Spätestens wenn konkrete Daten ins Spiel kommen, wird dies stark eingeschränkt. Bei typischen Businessanwendungen tendiert die Wiederverwendbarkeit gegen 0 (Heißt nicht das sie 0 beträgt).

    Man kann den Grad der Wiederverwendbarkeit erhöhen, wenn man gleichzeitig die Komplexität erhöht. Um eine Komponente wiederverwendbar zu machen, muss diese in der Regel stärker abstrahiert werden, als es im konkreten Projekt nötig (und häufig auch sinnvoll) ist. Wenn ich absehen kann das ein bestimmter Aspekt wirklich an mehreren Stellen nötig ist, mache ich dies auch - das ist aber nur selten wirklich der Fall.

    Wenn man gleichzeitig auch andere Aspekte wie TDD und IoC berücksichtigt, die ohnehin eine höhere Abstraktion erfordern, ist der Anteil sicherlich höher. Doch ich kenne kaum Projekte die TDD betreiben (ins Besondere bei C++ Projekten; selbst wenn es spätestens bei langlebigen Projekten durchaus sinnvoll wäre), und wo diese Abstraktion nicht die Entwicklungszeit unnötig erhöhen würde.

    In zumindest meiner Praxis hat OOP nur wenig Wiederverwertbarkeit bedeutet. Nur die grundlegenden Bereiche (etwa auf dem Abstraktionsgrad der Standardbibliothek) waren für andere Projekte geeignet.

    Buchautoren nenne ich keine*, ich lese sehr viel und mir ist in den letzten 5 Jahren ein Sinneswandel bei den Aussagen zur Wiederverwendbarkeit aufgefallen. Einst als einer der primären Hauptgründe für OOP dargestellt, wird es inzwischen eher am Rande und mit Einschränkungen präsentiert. Ähnliches gilt für die Meinung im Netz zu selbigen Thema.

    * Dazu ist die von mir konsumierte Buchzahl einfach zu hoch, und der Aufwand zum Suchen der Textpassagen zu aufwendig.



  • Hallo asc,

    danke für dein relativierendes Posting.
    Wir betreiben halt hauptsächlich C# Entwicklung. Da haben wir eine Unit-Test-Abdeckung von 70-80% bei kleineren Projekten (~5000 bis 10.000 LOC) und zwischen 30% und 50% bei größeren Projekten (Prozentzahlen maschinell ermittelt mit Visual Studio Test Coverage Analyzer).
    Der Code ist relativ abstrakt gehalten und hier können wir relativ viel wiederverwenden.

    Ich gebe aber zu, dass es fast immer einen Trade-Off zwischen Wiederverwendbarkeit und einfacher Implementierung gibt. Das ist tatsächlich von Fall zu Fall abzuschätzen.


Anmelden zum Antworten