techlogs Mehr als Bits und Bytes

Softwaredesign und Programmiersprachen...

von Rainer Gerhards, 16. Oktober 2009, 14:52

Welche Programmiersprache die "Beste" sei, führt oft zu fast religiös anmutenden Diskussionen unter Programmierern. Aber darf die Wahl der Programmiersprache das Design eines Softwaresystems entscheidend beeinflussen? Muss dieses Design anders sein, wenn in C implementiert wird, als wenn in Java implementiert wird?

Ich verwende momentan primär C, da meine aktuellen Projekte im Linux-Systemumfeld angesiedelt sind und dies dort (immer noch) die "Sprache der Wahl" ist. Allerdings meine ich, auch anderen Sprachen gegenüber recht aufgeschlossen zu sein (und diese auch immer wieder zu verwenden). So halte ich beispielsweise auch Java für eine sehr schöne Sprache, in der vieles sehr viel schneller, besser und eleganter als in C (oder auch C++) geht.

In den letzten Tagen habe ich eine für mich sehr interessante Diskussion darüber geführt, inwiefern die Programmiersprache über das Grunddesign eines IT-Systems entscheidet. Wenn ein solches System entwickelt werden soll, so muss man zunächst ein Modell des Sachverhalts entwickeln, und kann diesen dann in einem Programmsystem abbilden. Dabei geht es darum, inwiefern ein Systemdesign für objektorientierte Sprachen (prominenter Vertreter Java) und imperative, also nicht-objektorientierte, Sprachen (prominenter Vertreter C) anders ausschauen muss.

Ich möchte hier einige von mir geäußerte Gedanken vorstellen und würde mich über Feedback sehr freuen. Ich erhebe keinerlei Anspruch darauf, dass meine Gedanken wirklich korrekt sind, betrachte sie aber als das Ergebnis aus über 25 Jahren IT-Erfahrung. Insofern bin ich sicherlich ein wenig starrköpfig ;)

Der Text ist bewusst als Diskussionbeitrag geschrieben, ja einem solchen wirklich entnommen. Ich hoffe, das macht ihn lebendiger lesbar. Nun denn:

Mein Punkt ist, dass das Design einer Anwendung sich an den Realwelt-Objekten ausrichten sollte. Es gibt keinen Grund, in Assembler oder Pascal Spaghetticode zu programmieren, nur weil diese Sprachen nicht zwingend die Sichtweise nach Objekten erfordern. Wenn man z.B. in die Realisierung von Betriebssystemen schaut, dann werden natürlich Threads als Thread-Objekte (oder halt spezielle Prozesse), Prozesse als Prozess-Objekte, Platten als Speicherresource-Objekte etc. modelliert (und das auch in Betriebssystemen, die nicht in Java geschrieben sind...). Und natürlich gibt es für Treiber abstrakte Schnittstellen, die dann von konkreten Treiberklassen ausgefüllt werden müssen. Alle diese Überlegungen gibt es nämlich schon sehr lange, und die objektorientierten Sprachen sind ja nicht zuletzt entstanden, um diese Sichtweise auch vergleichsweise einfach in der Programmierung anwenden zu können und damit eine erhebliche Arbeitserleichterung (und Qualitätsverbesserung) zu erreichen.

Ich wüsste keinen Grund, warum man explizit auf eine Modellierung mittels interagierender Objekte verzichten sollte. In diesem Sinne halte ich das Systemdesign in der Tat für prinzipiell programmiersprachenneutral. In der Umsetzung des Designs stellt sich dann natürlich die Frage nach der Implementierungssprache. Natürlich kann ich ein objektorientiertes Design am leichtesten in einer OO-Sprache umsetzen. Und natürlich haben die verschiedenen Programmiersprachen verschiedene Vor- und Nachteile. Aus meiner Sicht eignen sich daher gewisse Programmiersprachen für gewisse Problemstellung mehr oder weniger gut.

Aber ich muss doch von der Problemstellung aus schauen. Ich darf doch nicht die Problemstellung "passend machen" und in einer wie auch immer gearteten Weise ein "C-Design" machen, nur weil C das "nun einmal nicht anders kann". Oder das Problem an die Möglichkeiten von Java anpassen. Mein Ziel sollte es doch zuerst einmal sein - auf oberer Ebene - ein System zu designen, dass die zu lösenden Sachverhalte modelliert.

Eine Anpassung des Problems an die (ggf. zu geringen) Möglichkeiten der Programmiersprache wird in der Praxis zwar durchaus schon einmal vorgenommen, aber ich habe selten erlebt, das sich daraus dauerhaft erfolgreiche Lösungen ergeben.

Natürlich muss ich auf etwas tieferer Ebene auch die Eigenschaften der verfügbaren Sprachen ("Was können meine Programmierer?") und des bereits vorhanden Codes ("Was kann ich wie wiederverwenden?") mit beachten, und das wird u. U. auch Design-Entscheidungen auf höherer Ebene beeinflussen. Aber ich kann nicht sehen, warum das Grunddesign anders aussehen muss, nur weil ich eine andere Sprache verwende.

Betrachten wir die Modellierung eines Motorrades (um es etwas griffiger zu betrachten):

Ein Motorrad besteht aus Rädern, Motor, ... Damit habe ich als Klassen doch schon einmal "Motorrad", "Rad", "Motor", ... und kann dann z.B. Subklassen von "Motor" bilden: "Viertaktmotor", "Zweitaktmotor" etc. Warum muss ich diese *Sichtweise* denn auf einmal aufgeben, nur weil ich in C (oder Pascal oder ...) programmiere?

Natürlich kann man das in Java eleganter implementieren. Aber mit einem ganz kleinen bisschen Disziplin kann ich doch auch in jeder anderen Sprache Konstruktoren (und ggf. Destruktoren) definieren, die entsprechenden Methoden, und ausserdem natürlich Methoden eng auf den zugehörigen Daten arbeiten lassen (wie man das in einer objektorientierten Sprache machen muss, bzw. machen sollte...). C zwingt mich doch nicht, das alles miteinander zu vermischen. Es  unterstützt mich nur nicht in gleicher Weise, wie es Java, ... macht. Und bei Vererbungshierarchien muss ich in einer nicht-OO Sprache natürlich sehr viel größeren Aufwand treiben. Das kann, je nach sonstigen Bedingungen, natürlich dazu führen, dass ich in Java & Co implementiere. Aber es kommt eben auch auf die sonstigen Bedingungen an. Wenn ich z.B. eine neue Komponente in ein bestehendes, in Pascal geschriebenes, System einfügen möchte, dann werde ich dazu wahrscheinlich nicht Java verwenden, auch wenn die Implementierung damit deutlich schneller ginge.

All' das hat aber doch nichts damit zu tun, dass ich in jedem Fall ein "ordentliches Design" auf dem aktuellen Stand der Technik machen sollte. Und ein solches Design ist momentan ganz sicher objektorientiert. Ich würde es für sträflich halten, ein "Spaghetti-Design" zu machen, nur weil ich C, ... verwende.

In diesem Sinne sollte die Programmiersprache das Design eines Softwaresystems nicht massiv beeinflussen. Das zumindest ist mein Standpunkt. Über Diskussionen dazu würde ich mich in der Tat sehr freuen...



antworten

Artikel kommentieren
 authimage

Kommentare

  1. Adg kein Betreff
    15.01.2010 | 18:55

    Interessanter Artikel, entscheidend sind hier sicherliche mehrere Faktoren. Dazu zählt auch der Anwendungsbereich, jedoch würde auch ich für nahezu jeden Anwendungsbereich eine objektorientierte Sprache wählen.

  2. Miguel kein Betreff
    17.03.2010 | 02:08

    Es ist aber nicht nur die Problemstellung, sondern auch die zur Verfügung stehenden Ressourcen. Soll ich beispielsweise eine Webanwendung bauen und den Kunde hat nur einen ganz normalen Webspace bei Strato, dann werd ich wohl außer PHP keine andere Wahl haben. Hat er einen Windows-Server und ich stehe unter Zeitdruck, ist wohl C# die Sprache der Wahl. Habe ich genug Zeit und vielleicht auch die Wahl des Betriebssystems, kann ich natürlich ohne Probleme auch C++, Java oder sonstwas nehmen.

    Ganz persönlich mag ich es am liebsten, wenn ich eine verteilte Anwendung in mehreren Sprachen schreiben darf, die am besten noch mehrere Datenbanksysteme und unterschiedliche Transportprotokolle nutzen. Sowas macht dann wirklich Spaß.

Artikel kommentieren
szmtag