Programmier/Designansätze: Wie stark generalisieren?



  • Hallo,

    meine Frage geht ein bisschen in Richtung dieses alten Threads:
    https://www.c-plusplus.net/forum/261002

    Ich arbeite im wissenschaftlichen Umfeld. Es geht also insbesondere um kleinere Tools/Prototypen und die Software wird nicht verkauft oder an außenstehende weitergegeben.

    Wie stark generalisiert ihr oder sollte man die Komponenten eines C++ Programmes generalisieren? Ich habe nämlich gemerkt, dass ich/meine Kollegen oftmals alle Teile schön generisch schreiben (insbesondere mit Templateparameter), sodass man sie für alle zukünftigen theoretischen Einsatzgebiete wiederverwenden kann. Das bläht den Code natürlich auf. In fast allen Fällen bleibt es aber bei der theoretischen Wiederverwendung. Daher geht relativ viel Zeit für "unnötige" Arbeit drauf.

    Gibt es Konzepte die sich damit beschäftigen, wann man konkret und wann generisch bleiben sollte? Mit fällt das KISS Prinzip ein.
    Eine gute Richtlinie war für mich bis jetzt, dass ich eine Unterscheidung zwischen konkreter Anwendung und Bibliothek gemacht habe. Bibliotheken sollen ja oftmals sehr generell sein, da man den genauen Anwendungszweck ja noch nicht exakt kennt. Wie sollte man dies bei den konkreten Tools handhaben?

    Allgemeine Aussagen sind natürlich immer schwer, aber vielleicht gibt es dazu ja Literatur. Es geht in Richtung Softwaredesign, aber nicht um sehr große Projekte, welche über Jahre wachsen.

    Viele Grüße



  • MatheMann schrieb:

    Wie stark generalisiert ihr oder sollte man die Komponenten eines C++ Programmes generalisieren?

    Das hängt bei mir weit mehr vom Anwendungsfall als der Sprache ab.

    MatheMann schrieb:

    Es geht also insbesondere um kleinere Tools/Prototypen und die Software wird nicht verkauft oder an außenstehende weitergegeben.

    Umso kleiner und kurzlebiger eine Software ist, umso weniger Aufwand würde ich beim Design als nötig erachten. Wenn eine Software wiederum größer und permanent weiterentwickelt wird, halte ich einen hohen Designaufwand für gerechtfertigt und sinnvoll.



  • Das es um kleine interne Tools geht würde ich sagen, mach nur soviel wie nötig. Overengineering hilft niemandem. Sollte die Wiederverwendung mal von der Theorie in die Praxis wechseln kann man immer noch anpassen.



  • Ich habe noch ein bisschen Recherche betrieben. Folgende schöne Links habe ich dabei gefunden.

    Aus dem alten Thread: http://thinking-forth.sourceforge.net/
    Kurz gehalten: http://www.itexico.com/blog/bid/99765/Software-Development-KISS-YAGNI-DRY-3-Principles-to-simplify-your-life
    Relativ umfangreich und sehr gut: http://c2.com/cgi/wiki?YouArentGonnaNeedIt

    Ein Zitat aus dem dritten Link, das es auf den Punkt bringt:

    RonJeffries schrieb:

    A scenario from RonJeffries explains the practices:
    You're working on some class. You have just added some functionality that you need. You realize that you are going to need some other bit of functionality. If you don't need it now, don't add it now. Why not?
    "OK, Sam, why do you want to add it now?"
    "Well, Ron, it will save time later."
    But unless your universe is very different from mine, you can't 'save' time by doing the work now, unless it will take more time to do it later than it will to do now. So you are saying:
    "We will be able to do less work overall, at the cost of doing more work now."
    But unless your project is very different from mine, you already have too much to do right now. Doing more now is a very bad thing when you already have too much to do.
    And unless your mind is very different from mine, there is a high chance that you won't need it after all, or that you'll need to rewrite or fix it once you do need it. If either of these happens, not only will you waste time overall, you will prevent yourself from adding things that you do need right now.



  • MatheMann schrieb:

    Ich habe noch ein bisschen Recherche betrieben. Folgende schöne Links habe ich dabei gefunden.

    ...

    Ein Zitat aus dem dritten Link, das es auf den Punkt bringt:

    RonJeffries schrieb:

    A scenario from RonJeffries explains the practices:
    You're working on some class. You have just added some functionality that you need. You realize that you are going to need some other bit of functionality. If you don't need it now, don't add it now. Why not?...

    Generalisierung ist aber nicht zwangsweise das Hinzufügen von Funktionalitäten. Was nicht heißt das Generalisierung immer sinnvoll ist. Es gibt durchaus Designansätze, über die man relativ früh im Projekt eine Entscheidung treffen sollte, weil sie sich nachträglich nur mit hohen Kosten umsetzen lassen. Nachträglich eine Schichtentrennung einzufügen ist beispielsweise extrem schwer. Daher gibt es Entscheidungen die an der Projektgröße und absehbarer Projektlebenszeit hängen.

    Etwas anderes ist, ob man an jeder Stelle alles massiv aufbohrt, auch wenn man nicht abschätzen kann ob es jemals nötig ist.



  • Mittelweg finden hilft. Wobei ich mit der Zeit immer mehr den pragmatischen Ansatz wähle. So einfach wie nur möglich, aber dafür sauber.

    Kenne Software, wo Leute gemeint haben, sie müssen alle Design Pattern aus GOF anwenden. Das ist mindestens genauso schlimm wie C Spaghetti Code.



  • MatheMann schrieb:

    Es geht also insbesondere um kleinere Tools/Prototypen und die Software wird nicht verkauft oder an außenstehende weitergegeben.

    Wie stark generalisiert ihr oder sollte man die Komponenten eines C++ Programmes generalisieren?

    Kleine Tools und auch Prototypen generalisiere ich gar nicht, die haben manchmal noch nicht mal irgendwas von OOP drin.

    Immer das richtige Werkzeug für das Projekt nutzen, nie mehr als nötig. Ich vermeide sogar oft C++, wenn ich es nicht zu 100% brauche, da mir andere Sprachen einfach leichter von der Hand gehen oder besser zu nutzende Libs haben. Ich programmiere in C, C++, Java, PHP, Javascript, Python und Bash. C und C++ wird von mir schon extrem selten gebraucht, da ich selten Libs schreibe sondern lieber welche nutze, dann aber eher in den anderen Sprachen. Arbeitszeit und so wenig Stress wie möglich ist mir wichtiger als das letzte bisschen Performance.

    Das Wichtigste ist, dass wenn möglich auch andere Programmierer leicht meinen Code verstehen und damit arbeiten können. C++ + viel Generalisierung ist aber genau das Gegenteil davon, das ist kontraproduktiv.


Anmelden zum Antworten