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

otze

SideWinder schrieb:

Das trifft ja mal wohl für 90% der Softwareentwickler nicht zu. Also klingt mir der Absatz stark nach verallgemeinertem Quatsch.

Ich habe "ich" geschrieben. Aber du darfst auch ruhig Argumente zum Rest bringen.

SideWinder

otze schrieb:

SideWinder schrieb:

Das trifft ja mal wohl für 90% der Softwareentwickler nicht zu. Also klingt mir der Absatz stark nach verallgemeinertem Quatsch.

Ich habe "ich" geschrieben.

Hört sich wie ein "jeder" an wenn man liest

Beispiel bevor es ausratet: "Ich muss heutzutage studieren um einen guten Job zu bekommen.", heißt wohl nicht, dass ich damit unbedingt nur mich meine. Aber wenn du es so korrigierst, ok. Keine weitere Diskussion nötig.

MfG SideWinder

tntnet

otze schrieb:

Eventuell sogar mit einem Treiberinterface, wo ich Oracle durch eine andere Datenbank austauschen kann.

Nun reden wir von Abstraktion. Aber dein "eventuell" besagt, dass du das eventuell gar nicht implementiert hast?

Warum so negativ? Das http://new.tntnet.org/howto/tntdb.html habe ich implementiert. Freut mich aber, dass Du mir dann doch noch Recht gibst.

Ach ja. Wie wäre es mit einem Abstraktionsinterface zu rpc? http://new.tntnet.org/howto/rpc-howto.html. Da kann man das verwendete RPC Protokoll ohne Codeänderungen austauschen.

Ich wollte nur ein paar einfache Beispiele bringen, um es leichter verständlich zu machen.

Sone

tntnet schrieb:

otze schrieb:

Eventuell sogar mit einem Treiberinterface, wo ich Oracle durch eine andere Datenbank austauschen kann.

Nun reden wir von Abstraktion. Aber dein "eventuell" besagt, dass du das eventuell gar nicht implementiert hast?

Warum so negativ? Das http://new.tntnet.org/howto/tntdb.html habe ich implementiert. Freut mich aber, dass Du mir dann doch noch Recht gibst.

conn.execute(
      "create table t1(col1 int not null primary key,"
      "                col2 int not null)");

Was zum Teufel soll denn das sein?

Kellerautomat

Ein SQL Statement?!

Sone

Kellerautomat schrieb:

Ein SQL Statement?!

Achso, gut. Ich dachte schon..

volkard

wikileaks schrieb:

otze schrieb:

Es kann sein, dass die gefühlte Komplexität in einem bestimmten Anwendungsfall geringer wird, aber die Komplexität über das Gesamte Programm steigt an:

Nicht in meinem Verständnis vom Artikel.

Programmkomplexität = Aufgabenkomplexität - (1-Leakyness)*Abstraktion

Leakyness ist zwischen 0% (triviale Abstraktion), 20% (Normalfall), 50% (gutes grösseres Projekt) und >100% (absoluter Design-Fail).

Ich möchte kein Programm ohne Abstraktion (=strukturloser Assemblercode) schreiben, auch kein kleines.

Abstraktion:

Mehr Interfaces
Mehr Klassen
Weniger Code
Weniger Dinge zu lernen
Weniger mögliche Fehlerquellen

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.

Eisflamme

Trotzdem folge ich nicht dem Java-Stil. Natuerlich habe ich eine Socketklasse, eine fuer RS232 und ... trotzdem erben sie nicht von einem Interface obwohl sie alle ein wait_for_event() und read(...) haben.

Zumindest teilweise ist das in C++ auch nicht nötig, weil Templates so stark sind. Es ist in Java immer nötig, dass man erbt, damit man irgendjemandem ein Interface-Objekt übergeben kann. In C++ kann man so was oft auch als Template-Parameter reinreichen und die Funktionen aufrufen, da braucht kein Mensch ein Interface.

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.

Um für den Fall zu wappnen, kann man halt ein Interface drüberschrauben. Erhalten Anwendungsklassen dann nur das Interface und nicht das Socket direkt, hat man abstrahiert. Würde man in Java dann direkt mit Factories verbinden und zack, hat man zig Klassen.

tntnet:
Na ja, dass der Anwendungscode kürzer wird, wenn Du Dinge rausziehst und in eine Toolbox/Library steckst, ist klar. Aber mit der Definition wäre ja z.B. bei einer Server/Client-Anwendung automatisch jede Implementierung mit einem Null-Client weniger komplex als mit einem Fat Client. Es geht schon um die gesamte Software.

volkard

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.

Eisflamme

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.

asc

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).

knivil

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: ... .?!

Mechanics

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.

asc

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).

Tyrdal

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?

Mechanics

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.