Statische Versus Dynamische Typisierung
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Warum gibt es eigentlich so viele einzelne Seiten zu diesem Thema? Kann man die zusammenfassen? -- HenningThielemann

Statisch typisierte Sprachen überprüfen Typ-Konformität zur Übersetzungszeit, während dynamisch typisierte Sprachen dies erst zur Laufzeit tun. Mit statischer Typisierung lassen sich eine Reihe von "dummen" Fehlern finden, noch bevor das Programm das erste Mal gestartet werden kann. Mit sorgfältig gewählten Typen kann man ein Programm noch lesbarer machen und gibt insbesondere dem Übersetzer die Möglichkeit, Unstimmigkeiten aufzudecken. Statisch typisierte Sprachen unterscheiden sich allerdings in der Vielfalt der Typen. Je feiner unterschieden wird, desto mehr Sicherheit ist möglich und um so mehr Sorgfalt verlangt die Typenwahl.

Die meisten statisch typisierten ProgrammierSprachen wie z.B. SpracheAda, SprachePascal, SpracheModula2?, SpracheModula3, SpracheOberon, SpracheCee, SpracheCpp oder die SpracheJava, zwingen den Programmierer dazu, die Datentypen aller verwendeten Variablen und Parameter von Funktionen und Methoden zu deklarieren. In der SpracheHaskell ist es ein vom Übersetzer angemahnter Schönheitsfehler, wenn Typdeklarationen weggelassen werden. Der Übersetzer kann aber auf Wunsch den Typ eines Ausdruckes berechnen.

Es ist eigentlich überflüssig zu sagen: Natürlich findet man mit diesem Konzept nicht alle Fehler, aber jeder Schutzmechanismus erhöht die Sicherheit. Die Frage sollte also nicht sein "Statische Typisierung oder nicht?" sondern "Statische Typisierung und was sonst noch?"

Aber: Statische Typisierung nimmt einer Sprache einiges an Dynamik. Und da stellt sich dann unter anderem die Frage, ob der Mehraufwand bei der Programmierung nicht auch zu mehr Fehlern führt. Ein Ausweg aus dem Dilemma stellen optionale Typannotationen dar, ein anderer sind Generics. Typecasts brechen das Konzept der Typisierung, auch beim sogenannten Autoboxing. Typinferenzer können dem Programmierer Arbeit abnehmen. Mit in das Thema spielen auch verschiedene Typ-Konzepte wie Interfaces, Mixins oder Traits.


Siehe auch TypSicherheit

Diskussion

Wenn ein Softwaresystem im Sinne von ExtremeProgramming mit KomponentenTests versehen wurde, gibt dies eine erheblich höhere Sicherheit vor allen Arten von Fehlern, wobei auch Typfehler mit großer Wahrscheinlichkeit erkannt werden.

Wenn der Typkonflikt bei einer Sprache mit später Bindung erst zur Laufzeit auftreten kann, muss er durch einen Test nicht sicher erkannt werden. Für Typkonflikte, die durch eine statische Analyse eines Quelltextes gefunden werden können, ist eine automatisierte statische Analyse mindestens so nützlich wie ein Test. Was tragen KomponentenTests zur Entdeckung von Typkonflikten bei? -- KurtWatzka

Ich kann das nur aus der theoretischen Sicht eines Beobachters beurteilen. Die XP-KomponentenTests sind wirklich umfassend und Testen jede Kleinigkeit. Der Aufwand dafür ist hoch. Das vielbeschriebende C3Projekt hat mehr Code in den Tests (ca. 30000 Tests?, ich hab die Zahl nicht mehr im Kopf) als im eigentlichen Programm. Ich nehme an, dass in Smalltalk und bei ungewisser Qualität der Programmierer eine andere Vorgangsweise gar nicht möglich ist. Nicht mein bevorzugter Stil, aber doch ein plausibler Denkansatz. -- HelmutLeitner

Ich habe für eine kleine Programmierübung an der TU einmal TestgetriebeneEntwicklung in der SprachePython ausprobiert. Ich habe doppelt soviel Testcode wie funktionellen Code gehabt aber dafür habe ich genau einen Programmierfehler gemacht und der war - dank der Tests - offensichtlich zu beheben.

Ein Typfehler in Smalltalk ist ein Message Send an ein Objekt, welches die gesendete Botschaft nicht versteht (oft ist das Objekt nil, eine ziemlich "dummes" Objekt der Klasse UndefinedObject?). Unentdeckte Typfehler in Smalltalk sind relativ selten. Dass sie sich erst zur Laufzeit bemerkbar machen, wird durch zwei Programmierparadigmen ausgeglichen:

Das beschriebene "test first" ist erst seit ein paar Jahren in Mode gekommen. Warum dies erst mit XP (und damit eben auch mit Smalltalk) trendy wurde, ist mir ein Rätsel. Ohne Regressionstests bekäme ich vermutlich kein stabiles C++ Programm hin.

Programmieren während das Programm läuft. Soetwas habe ich bislang nur in Smalltalk erlebt, wo man im Debugger programmieren kann; mit dynamisch typisierten Sprachen und langen Übersetzungszyklen sicher nur schwer realisierbar, in Smalltalk tägliches Brot.

In Visual Basic for Applications (VBA) kann man auch laufendes Programm im Debugger bearbeiten. Im Visual C++ kann man auch im Debugger Teile des Programms neu übersetzen und weiterlaufen lassen, allerdings klappt es nicht immer. -- GregorRayman

Siehe auch StatischOderDynamischTypisiert. -- SaschaDördelmann

Bleiben wir beim Beispiel eines Stacks. Der Fehler, bei dem ich besorgt wäre, ob er durch einen Modultest sicher gefunden werden kann, ist der, dass verschiedene Nutzer des Stacks Objekte auf den Stack packen und nicht damit rechnen, dass auch andere Nutzer (nicht Anwender sondern Module) mit dem Stack arbeiten, so daß der Zugriff auf das oberste Stackelement ein Objekt vom falschen Typ liefert.
Nur ein Integrationstest kann solche Fehler sicher finden. Eine Sprache, die Stacks typsicher macht, verhindert schon die versehentliche Verwendung eines Stacks von Aufträgen als Stack von Vorher/Nachher-Beziehungen --kw


StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 24. Januar 2005 10:09 (diff))
Suchbegriff: gesucht wird
im Titel
im Text