Grundlagen der Programmierung: Codemetriken

Instabilität vs. Abstraktion

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Ohne Abhängigkeiten kommt kein Programm aus. Dieser Graph stellt sie zum Abstraktionsgrad ins Verhältnis, um echte Qualitätseinschätzungen zu erlauben.
07:27

Transkript

Auch auf die Gefahr hin, dass ich mich wiederhole, man muss mit Abhängigkeiten immer ein wenig aufpassen, aber Abhängigkeiten lassen sich auch nicht vermeiden. Wir betrachten anhand der Begriffe Instabilität und Abstraktion, wie wir im Alltag versuchen, Abhängigkeiten zu vermeiden, welche Arten von Abhängigkeiten es gibt und was wir bei dieser ganzen Geschichte beachten müssen. Grundsätzlich ist es so, dass wir in unserer Applikation immer Abhängigkeiten haben. Hier ein Abhängigkeitsgraph mit zwei äußeren Punkten, und zwar A und X. A ist transitiv von X abhängig, aber eben noch von ganz vielen anderen Bestandteilen. Was wir hier schon sehen, ist, es gibt theoretisch zwei unterschiedliche Arten von Abhängigkeiten. Mit A sehen wir den Extremfall der sogenannten "Efferent Coupling". "Efferent Coupling" beziehungsweise "Ausgehende Abhängigkeiten" zeigen auf, welche Bestandteile durch einen Bestandteil genutzt werden. Dies ist hier ein Extremfall, weil A eben nur solche "Ausgehenden Abhängigkeiten" hat. A ist nur von anderen Bestandteilen abhängig. Für A selbst ist das eher kritisch, weil Änderungen an den anderen Bestandteilen können sich in A niederschlagen. Ein typischer Fall ist, dass wir eine Methodensignatur anpassen und dann natürlich auch alle Aufrufe dieser Methode anpassen müssen. Aufgrund dieser Abhängigkeiten ist A also weniger stabil. Es unterliegt einer höheren Wahrscheinlichkeit von Änderungen, weil andere Bestandteile ja geändert werden könnten. Einer dieser Bestandteile könnte beispielsweise X sein. X zeigt ein Extrem der entgegengesetzten Art von Abhängigkeiten, und zwar das "Afferent Coupling" beziehungsweise der "Eingehenden Abhängigkeit". Für X besteht hier kein Problem, denn es hat keinen Nachfolger. Änderungen an anderen Stellen werden sich also in X nicht niederschlagen. X selbst ist demnach sehr stabil. Um solche Abhängigkeiten nun zu beseitigen beziehungsweise einzuschränken, können wir die Abstraktionen nutzen. Abstraktionen können wir aber auch nur in einem bestimmten Grad verwenden, also, die Effizienz und Performance unserer Applikation leidet ja unter zu viel Abstraktion. Und wir müssen einen Weg finden, zu bewerten, wann wir einen guten Abstraktionsgrad und wann einen schlechten Abstraktionsgrad haben. Das machen wir, indem wir die beiden Begriffe Instabilität und Abstraktion erfassen, also diese beiden Qualitätsmerkmale, und diese im Verhältnis zueinander stellen. Die Instabilität wird errechnet anhand der ausgehenden Abhängigkeiten des "Efferent Couplings" geteilt durch alle Abhängigkeiten, die bestehen. Die Abstraktion wiederum ist eben die Anzahl der abstrakten Typen beziehungsweise abstrakten Bestandteile geteilt durch die Anzahl aller Bestandteile. Wir bekommen demnach für beides einen Wert zwischen 0 und 1. Wenn wir beides nun in ein Diagramm einzeichnen, beispielsweise hier auf der linken Seite "Abstractness" für die Y-Achse und für die X-Achse "Instability" sowie die Maximalwerte, dann können wir bestimmte Bereiche ausmachen. Haben wir beispielsweise eine Bibliothek, die nur Schnittstellen enthält, dann ist diese sehr abstrakt. Sie sollte zeitgleich, aber auch sehr stabil sein. Sie sollte möglichst wenige andere Bestandteile nutzen, denn je weniger Bestandteile sie nutzt beziehungsweise je weniger sie selbst angepasst wird, desto weniger müssen wir andere Bestandteile anpassen. Dem gegenüber müssen Bestandteile, die nicht abstrakt sind, nicht zwangsläufig stabil sein, wenn sie weniger eingehende Abhängigkeiten haben. Also, wenn etwas nur andere Bestandteile nutzt, aber selbst nicht benutzt wird, dann ist keine Abstraktion notwendig. Wogegen sollte ich das denn abstrahieren beziehungsweise wofür? Das sind häufig Bestandteile, die unsere Applikationen zusammenbauen. Die nutzen andere Dinge wie einen Bootstrap oder Ähnliches. Sie sind anderen Bestandteilen aber eben nicht bekannt. Dann gibt es noch die Extremfälle. Etwas ist nicht abstrakt, wird aber sehr viel von anderen Stellen genutzt. Das kenne ich aus meiner Zeit, als ich angefangen habe, zu programmieren. Da habe ich dazu geneigt, alles in riesengroße Klassen zu packen, die sogenannten Gott-Klassen. Nach einiger Zeit wurde es immer schmerzhafter, die zu verwenden, weil man ewig am Debuggen war. Und jede Änderung hat sich gleich an Tausend anderen Stellen niedergeschlagen. Und dieser Schmerz, den man da fühlt beim Debuggen und beim Refrakturisieren und Ähnlichem, hat dazu geführt, dass man diesen Bereich auch als die "Zone of Pain" bezeichnet. Also Dinge, die in die "Zone of Pain" fallen, weisen zu wenig Abstraktion im Verhältnis zu ihrer Instabilität auf, zu dem Grad, in dem sie selbst genutzt werden. Dem gegenüber kann es auch Bestandteile geben, die sehr abstrakt sind, aber gar nicht von anderen Bereichen genutzt werden. Diese sind weitestgehend sinnlos beziehungsweise nutzlos, weswegen man in diesem Bereich auch von der "Zone of Uselessness" spricht. Sie sehen schon, um den idealen Weg zu finden, sollte man sich quasi an einer Diagonalen bewegen und wie gut man sich auf dieser Diagonalen bewegt, kann man anhand der Distanz ausrechnen. Also je nachdem, wie das Verhältnis zwischen Abstraktion und Instabilität ist, erhalten wir eine Distanz zum Idealwert. Und das ist zum Beispiel einer dieser Werte, der dann auch von Code Metric Tools mit angegeben werden kann. Das Ganze kann dann auch noch in angepasster Form passieren, damit das etwas leichter übertragbar ist. Je nachdem, welches Tool Sie verwenden, kann dabei die eine oder andere Darstellung verwendet werden. Eine Darstellung beispielsweise findet sich in den XDepend- beziehungsweise NDepend-Tools. Das Ganze sieht dann aus wie hier. Dort wird eben diese Ideallinie eingezeichnet beziehungsweise die Distanz zur Ideallinie, die als gut, weniger gut und schlecht gilt. Das Bild, was Sie hier sehen, ist auch etwas, das ich in der Praxis immer häufig sehe, dass eben sehr viele Bestandteile sich eher so im rechten, unteren Bereich sammeln. Sie sind wenig abstrakt, werden aber auch von wenigen Bestandteilen genutzt. Und dann gibt es so bestimmte Sachen, die immer weiter nach links rutschen. Das kann dann beispielsweise eine Berechnungslogik sein, die von vielen Stellen benutzt wird und so weiter und so fort. Sie haben also auf diese Art und Weise jetzt die Zusammenhänge zwischen Abstraktion und Abhängigkeiten kennengelernt beziehungsweise auch die unterschiedlichen Arten von Abhängigkeiten und deren Zusammenhänge.

Grundlagen der Programmierung: Codemetriken

Lernen Sie Methoden, Prinzipien und Werkzeuge kennen, mit deren Hilfe Sie die Qualität Ihrer Software dauerhaft sicherstellen können.

1 Std. 43 min (20 Videos)
Derzeit sind keine Feedbacks vorhanden...
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.04.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!