Die POCO C++ Libraries sind eine Sammlung von Open-Source-Klassenbibliotheken zur Entwicklung portabler, netzwerkorientierter Anwendungen in C++. POCO C++
POCO steht für POrtable COmponents. Die Bibliotheken bieten Funktionen für Threads und Thread-Synchronisierung, Dateisystemzugriffe, Streams, Shared Libraries und das Laden von Klassen, Sockets sowie Netzwerkprotokolle wie HTTP, FTP und SMTP. Außerdem enthalten sie einen HTTP-Server, einen XML-Parser mit SAX2- und DOM-Schnittstellen sowie Zugriff auf SQL-Datenbanken.
Dank ihres modularen und effizienten Designs und ihrer Implementierung eignen sich die POCO C++ Libraries sehr gut für die Embedded-Entwicklung.
Werfen wir mit CppDepend einen Blick in POCO und untersuchen einige Aspekte der Implementierung und des Designs. CppDepend
POCO-Implementierung
Number of lines of code
Methoden mit vielen Codezeilen sind schwer zu verstehen und zu warten. Suchen wir nach Methoden mit mehr als 60 Zeilen.
Weniger als 1 % der Methoden haben mehr als 60 Zeilen.
Cyclomatic Complexity
Die zyklomatische Komplexität ist eine verbreitete prozedurale Softwaremetrik und entspricht der Anzahl möglicher Entscheidungen innerhalb einer Prozedur.
Führen wir die folgende CQLinq-Abfrage aus, um Methoden zu erkennen, die refaktoriert werden sollten:
Damit können nur 1 % der Methoden als komplex angesehen werden.
Which methods are complex and insufficiently documented?
Methods with many variables
Methoden mit einem NbVariables-Wert über 8 sind schwer zu verstehen und zu warten. Liegt NbVariables über 15, sind sie äußerst komplex und sollten in kleinere Methoden aufgeteilt werden – sofern sie nicht automatisch von einem Tool generiert wurden.
Nur 8 Methoden enthalten zu viele Variablen.
Types with many methods and fields
Nur 3 % der Typen besitzen viele Methoden.
Dieselbe Suche können wir auch für Felder durchführen.
Weniger als 1 % der Typen besitzen viele Felder.
Wir können daraus schließen, dass POCO gut implementiert ist: Nur wenige Methoden gelten als komplex, die Typen sind einfach aufgebaut und besitzen vergleichsweise wenige Methoden und Felder, und der Code ist gut dokumentiert.
DESIGN
Abstract vs instability
Das Diagramm „Abstractness vs. Instability“ kann dabei helfen, Projekte zu erkennen, die sich nur schwer warten oder weiterentwickeln lassen. Der folgende Beitrag erläutert den Nutzen dieses Diagramms und zeigt, wie es zur Verbesserung des Designs eingesetzt werden kann. post
Für POCO sieht das Diagramm „Abstractness vs. Instability“ wie folgt aus:
Nur Foundation befindet sich in der „Zone of Pain“, was verständlich ist, da dieses Projekt von vielen anderen Projekten intensiv genutzt wird.
Inheritance
Mehrfachvererbung erhöht die Komplexität und sollte daher mit Bedacht eingesetzt werden.
Suchen wir nach Klassen mit vielen Basisklassen.
Die blauen Rechtecke stellen das Ergebnis dar.
Nur wenige Klassen erben von mehr als einer Klasse.
Type cohesion
Das Single-Responsibility-Prinzip besagt, dass eine Klasse nicht mehr als einen Grund für Änderungen haben sollte. Eine solche Klasse gilt als kohäsiv. Ein hoher LCOM-Wert weist in der Regel auf eine geringe Kohäsion hin. Es gibt mehrere LCOM-Metriken. LCOM liegt im Bereich [0–1], während LCOMHS (HS steht für Henderson-Sellers) Werte im Bereich [0–2] annimmt. LCOMHS gilt häufig als besser geeignet, nicht kohäsive Typen zu erkennen. Ein LCOMHS-Wert über 1 sollte als Warnsignal betrachtet werden.
Nur 1 % der Typen gelten als nicht kohäsiv.
Efferent coupling
Die efferente Kopplung eines Typs entspricht der Anzahl der Typen, von denen er direkt abhängt. Typen mit TypeCe > 50 hängen von zu vielen anderen Typen ab. Sie sind komplex, haben häufig mehr als eine Verantwortung und sind gute Kandidaten für Refactoring.
Führen wir die folgende CQLinq-Abfrage aus.
Das Ergebnis ist leer; somit besitzt keine Klasse zu viele Verantwortlichkeiten.
Types most used
Es ist hilfreich zu wissen, welche Typen am häufigsten verwendet werden. Dafür können wir die TypeRank-Metrik nutzen.
TypeRank-Werte werden berechnet, indem der Google-PageRank-Algorithmus auf den Graphen der Typabhängigkeiten angewendet wird. Anschließend wird eine Homothetie mit dem Zentrum 0,15 angewendet, sodass der durchschnittliche TypeRank 1 beträgt.
Typen mit hohem TypeRank sollten besonders sorgfältig getestet werden, da Fehler in solchen Typen wahrscheinlich schwerwiegendere Auswirkungen haben.
Suchen wir nach Typen, die sowohl stark genutzt als auch komplex sind.
Das Ergebnis ist leer; keine Klasse ist gleichzeitig stark genutzt und komplex.
Layering and level metric
Dieser Beitrag erklärt die Level-Metrik und zeigt, wie sie zur Verbesserung des Designs genutzt werden kann. post
Suchen wir nach Abhängigkeitszyklen. Dazu können wir die folgende CQLinq-Abfrage ausführen:
Nur wenige Methoden sind an Abhängigkeitszyklen beteiligt. Nehmen wir das Zip-Projekt als Beispiel und betrachten seinen Abhängigkeitsgraphen.
In diesem Projekt existiert nur ein Abhängigkeitszyklus.
Zusammenfassend ist POCO auch gut konzipiert: Es weist eine hohe Kohäsion und eine geringe Kopplung auf.