Es gibt zahlreiche C++-Bibliotheken und -Frameworks, deren Einsatz die Entwicklung Ihrer Projekte beschleunigen kann. In diesem Beitrag untersuchen wir die Nachteile einer C++-Anwendung, die stark von einem externen Framework abhängig ist. Doch zunächst: Worin unterscheidet sich eine Bibliothek von einem Framework? Und warum kann eine enge Kopplung an ein Framework problematischer sein als eine enge Kopplung an eine Bibliothek?
Eine interessante Gegenüberstellung findet sich in diesem Beitrag:
The key difference between a library and a framework is "Inversion of Control". When you call a method from a library, you are in control. But with a framework, the control is inverted: the framework calls you.Ein Framework lässt sich auch folgendermaßen definieren:
It defines a skeleton where the application defines its own features to fill out the skeleton. In this way, your code will be called by the framework when appropriately. The benefit is that developers do not need to worry about if a design is good or not, but just about implementing domain specific functions.Zusammengefasst greift ein Framework stärker in eine Anwendung ein als eine Bibliothek und kann deren Architektur und Design maßgeblich beeinflussen.
Qt und MFC sind beispielsweise zwei bekannte C++-Frameworks. So werden sie auf ihren Websites beschrieben:
Qt:
Qt is a cross-platform development framework enabling your team to deploy a single codebase providing common APIs across all supported platforms.And MFC:
Your work with the Microsoft Foundation Class (MFC) Library framework is based largely on a few major classes and several Visual C++ tools. Some classes encapsulate a large portion of the Win32 application programming interface (API). Other classes encapsulate application concepts such as documents, views, and the application itself. Still others encapsulate OLE features and ODBC and DAO data-access functionality.Ein Framework greift stärker in die Anwendung ein. Ist eine Anwendung eng daran gekoppelt, sind nahezu alle Projektbeteiligten davon betroffen.
Recruiting: Ist ein Projekt eng an ein externes Framework gekoppelt, muss nahezu jeder Entwickler dieses Framework beherrschen. Das erschwert die Suche nach neuen Entwicklern, da gezielt C++-Entwickler benötigt werden, die bereits Erfahrung mit dem eingesetzten Framework haben.
Architekten und Designer: Bei einer engen Kopplung an ein externes Framework geht Flexibilität verloren, und jede Weiterentwicklung, Migration oder Anpassung des Projekts wird komplizierter.
Entwickler: Jedes Framework bringt eigene Komplexität mit sich. Ist es eng mit dem Projekt verzahnt, muss jeder Entwickler es beherrschen. Dadurch steigt die Projektkomplexität, was Entwicklungszeit und Qualität deutlich beeinflussen kann.
Tester: Eigener Code lässt sich nur schwer isolieren und testen, wenn er eng an ein Framework gekoppelt ist. Mitunter entsteht dadurch zusätzlicher Aufwand beim Testen der Anwendung.
Ein externes Framework kann die Projektentwicklung beschleunigen. Es sollte jedoch mit Bedacht eingesetzt und unnötige Kopplung so weit wie möglich vermieden werden.
Analysieren wir einige Open-Source-C++-Projekte und sehen wir uns an, welche Kenntnisse ein Entwickler benötigt, um in deren Entwicklungsteams einzusteigen.
Fall I: eMule-Projekt (http://www.emule-project.net)
Nach der Analyse des eMule-Projekts mit CppDepend sehen wir, dass es hauptsächlich das MFC-Framework und die Windows-API verwendet.
Prüfen wir, wie eng das Projekt an MFC gekoppelt ist. Dazu können wir CppDepend ermitteln lassen, welche Methoden MFC verwenden. Das Ergebnis zeigt der Treemap -Graph:
Wir sehen, dass nahezu alle Methoden das MFC-Framework verwenden. Die eMule-Codebasis ist somit sehr eng daran gekoppelt.
Wir können außerdem nach den am häufigsten verwendeten MFC-Klassen suchen:
MFC wird im gesamten Projekt eingesetzt: Verwendet werden unter anderem GUI-, Internet-, Archive- und Container-Klassen.
Diese enge Kopplung hat zwei wesentliche Nachteile:
- Die eMule-Algorithmen lassen sich nicht ohne Weiteres in anderen Projekten wiederverwenden; dafür müsste ebenfalls MFC eingesetzt werden.
- Jeder Entwickler, der am eMule-Projekt mitarbeiten möchte, muss MFC beherrschen.
Fall II: OpenSTA-Projekt (http://sourceforge.net/projects/opensta/)
OpenSTA ist in mehrere Projekte aufgeteilt. Hier sind einige der Projektabhängigkeiten:
Die Aufteilung eines Projekts in mehrere Module kann sehr vorteilhaft sein: Isolierte Funktionalität lässt sich leichter in anderen Projekten wiederverwenden und reduziert zugleich die Komplexität des Projekts.
Welche Projekte verwenden MFC?
Wir sehen, dass nicht alle Projekte das MFC-Framework verwenden und insbesondere die größten Projekte ohne MFC auskommen.
Welche MFC-Klassen werden verwendet?
OpenSTA verwendet hauptsächlich die OLE-Klassen.
Auch ein C++-Entwickler ohne tiefgehende MFC-Kenntnisse kann im OpenSTA-Team mitarbeiten, da viele Module MFC nicht direkt verwenden.
Zusammenfassung
Die Nutzung eines externen Frameworks zu isolieren, kann für alle Projektbeteiligten große Vorteile bringen. Halten Sie die Architektur möglichst einfach und vermeiden Sie unnötige Kopplung – insbesondere an die Business-Schicht.