Softwaredesign in C++ im Vergleich zu Softwaredesign in Java/C#
-
Eisflamme schrieb:
Möchte man hingegen zur Laufzeit auswählen können, welche Art von Socket man nutzt, während der Anwendungsteil mit allen "Arten" von Sockets umgehen kann, finde ich solch ein Interface schon sinnvoll. Du hattest wohl einfach nicht den Anwendungsfall, dass das notwendig ist.
Könnte mich jetzt auch nicht an so flexible Sockets erinnern.
-
Ich bin nicht so tief in Netzwerkprogrammierung drin. Wenn man so etwas praktisch nicht braucht, würde ich da auch kein Interface drüberbasteln. Ob das der Java-Programmierer immer sofort macht, weiß ich nicht. Das würde ich als schlechten Stil abstempeln in C++ genau so wie in Java.
-
volkard schrieb:
Beim Essen ist jedem klar, daß zu wenig schlecht ist und zu viel auch.
"Abstraktion" ist leider für die meisten viel zu abstrakt, um noch vernünftig zu bleiben.
Sehe ich ähnlich, und laufe doch immer mal wieder in Gefahr zu viel zu abstrahieren. Anderseits gibt es durchaus auch Programmteile von denen ich sehr sicher bin, das diese in nicht allzu weiter Zukunft erweitert und verändert werden müssen - dort kann eine Abstraktion durchaus angebracht sein.
Abstraktion kann sinnvoll sein, sollte aber nicht als Selbstzweck dienen. Wenn man in einem Projekt nur einen Fall abbilden muss, so ist Abstraktion meist unnötiger Mehraufwand der nur die Projektkomplexität erhöht. Ebenso würde ich Abstraktionen zur Wiederverwertung nur dort betreiben wo ohnehin eine Abstraktion Sinn macht (Wir Entwickler schießen viel zu gerne mit Kanonen auf Spatzen, manchmal glaube ich, das wir einen Todesstern auf eine Stecknadel loslassen würden).
-
Und jetzt sind wir fern ab von Gut und Boese. In den Tiefen des Allgemeinen und Unkonkreten, wo weder wahr noch falsch existiert, gut oder schlecht, Java, C++, C#, ... Da bleibt mir nur noch zu sagen: ... .?!
-
asc schrieb:
Abstraktion kann sinnvoll sein, sollte aber nicht als Selbstzweck dienen.
Naja
Ich gebs zu, ich bau öfter mal deutlich komplexeren Code als nötig, weil mich eine straight forward Implementierung langweilen würde. Programmieren muss ja auch Spass machen. Selbst wenn ich ein kleineres Teilprojekt einfach runtertippen und vergessen könnte, bau ich das öfter so auf, wie ich ein größeres/komplexeres Projekt aufbauen würde.
-
Mechanics schrieb:
asc schrieb:
Abstraktion kann sinnvoll sein, sollte aber nicht als Selbstzweck dienen.
Naja
Ich gebs zu, ich bau öfter mal deutlich komplexeren Code als nötig, weil mich eine straight forward Implementierung langweilen würde. Programmieren muss ja auch Spass machen.Privat ist da nichts gegen zu sagen, in einem bezahlten Projekt aber sollte man die Komplexität auch möglichst an den tatsächlichen Anforderungen und den wahrscheinlichsten Änderungen orientieren.
Es gibt Situationen wo es auch nicht verkehrt ist ein kleines Projekt wie ein größeres umzusetzen, wenn die Planung in die Richtung geht, dies über die Zeit entsprechend zu vergrößern - oder wo sich die Rahmenbedingungen schlicht und ergreifend geändert haben. Unser jetztiges Projekt soll z.B. nach C# portiert werden und war ursprünglich hauptsächlich für Einzelplätze oder zumindest nur wenige Benuzter ausgelegt.
Es ist bereits bekannt das die Planung dahin geht das wir größere Einrichtungen ansprechen wollen (und unsere größten Kunden geraten immer wieder an Grenzen der bisherigen Anwendung), und das der jetztige Teil langfristig nur noch einer von vielen Anwendungsbereichen sein soll. Das Projekt ist schon so groß und langlebig das sich hier Unittests mehr als auszahlen könnten, auch eine bessere Konfigurierbarkeit ist langfristig sinnvoll. Des weiteren sollte eine Mobilversion (die es bislang nicht gibt) möglichst viel Code mit der Clientanwendung teilen (Sprich Teile der Businesslogik sollten auf dem Server laufen).
Daher wird das Projekt definitiv komplexer als das bisherige.
Mechanics schrieb:
Selbst wenn ich ein kleineres Teilprojekt einfach runtertippen und vergessen könnte, bau ich das öfter so auf, wie ich ein größeres/komplexeres Projekt aufbauen würde.
Wenn nicht abzusehen ist das dies nötig wird, halte ich dies für falsch (sofern man es nicht gerade als Lernprojekt für größere Architekturen ausgelegt ist).
-
Mechanics schrieb:
asc schrieb:
Abstraktion kann sinnvoll sein, sollte aber nicht als Selbstzweck dienen.
Naja
Ich gebs zu, ich bau öfter mal deutlich komplexeren Code als nötig, weil mich eine straight forward Implementierung langweilen würde. Programmieren muss ja auch Spass machen. Selbst wenn ich ein kleineres Teilprojekt einfach runtertippen und vergessen könnte, bau ich das öfter so auf, wie ich ein größeres/komplexeres Projekt aufbauen würde.Du machst das aber nicht beruflich, oder?
-
Tyrdal schrieb:
Du machst das aber nicht beruflich, oder?
Natürlich. Privat programmiere ich so gut wir gar nicht mehr.
Ich sollte noch erwähnen, dass es keine "Projekte" sind. Wir haben unsere eigene Software, die sehr umfangreich ist und seit 20 Jahren entwickelt wird. Da ist es schon sehr schwer, von irgendeinem Feature zu behaupten, das bleibt genauso und wird nicht weiterentwickelt oder braucht sonst keiner.
Wenn man in kleineren Firmen arbeitet, ist es was anderes. Habe früher in mehreren kleinen Firmen gearbeitet, da waren so gut wie alle Aufträge unabhängig voneinander und gingen meist so über 2 Wochen. Bei so einem Projekt lohnt es sich natürlich nicht, unnötige Komplexität reinzubringen. Da ist es viel wichtiger, dass auch nach paar Jahren irgendjemand reinschauen und sofort einen Fehler beheben können muss, wenn der Kunde sich mal beschwert. So was würde ich eher so einfach wie möglich programmieren. Muss ich zum Glück nicht mehr machen
-
Mechanics schrieb:
Ich sollte noch erwähnen, dass es keine "Projekte" sind. Wir haben unsere eigene Software, die sehr umfangreich ist und seit 20 Jahren entwickelt wird.
Danke! Aber das ist langsam nicht mehr nötig. Wir wissen es bereits, da du nicht müde wirst, es bei jeder möglichen Gelegenheit einzuwerfen
-
An 20 Jahre alten Code rumbasteln, mein Beileid.