Falls ich mit dem DIP ein hypothetisches modulares C ++ Projekt entwickeln möchte. Aufgrund der Modularität habe ich beschlossen, ein bestimmtes Feature vollständig in einer Bibliothek A zu implementieren. Eine andere Bibliothek B (oder zwei oder drei ...) verwendet diese Funktion (z. B. einen Protokollierungsmechanismus):
Wo sollte ich diese Schnittstelle physisch platzieren? Einige Blogger scheinen darauf hinzuweisen, dass, weil die Schnittstelle ihren Benutzern gehört (wegen DIP) Sie müssen die Schnittstelle auf die Benutzerseite setzen (oder hier ). Dies würde auch die Testbarkeit verbessern, da Sie keine Implementierung benötigen, um mit dem Test verknüpft zu werden.
Dies würde bedeuten, dass die Bibliothek A selbst nicht kompiliert wird, weil ihr die Schnittstelle fehlt. Es bedeutet auch, dass wenn eine Bibliothek C auch die Protokollierungsfunktion verwendet , sie auch eine Schnittstelle ILogger einbringt, die die ODR ? Dies könnte durch Einführung einer zusätzlichen Paketschichtbibliothek D gelöst werden, die nur die Schnittstelle enthält. Aber das Hauptproblem bleibt:
Wohin mit der Schnittstelle? Ich lese die ursprüngliche Papier über DIP, aber ich kann der Interpretation nicht zustimmen, dass ich die nicht setzen sollte Schnittstellen in die Bibliothek. Ich habe das Gefühl, dass dieses Papier als Richtlinie für die Entwicklung gedacht ist ("die Benutzer definieren die Schnittstelle, nicht die Implementierer"). Ist das richtig? Wie verwenden Sie das Dependency Inversion-Prinzip?
Software kann als eine Kombination verschiedener Ebenen betrachtet werden:
Eine Ebene ist die Implementierungsebene (grob, die Funktionsebene)
Ein anderer ist die Art und Weise, wie Datenstrukturen miteinander interagieren (die Klassenebene, auf der sich hauptsächlich der DIP befindet)
Und noch ein anderer Weg, wie Komponenten miteinander interagieren sollen (die Paketschicht). Wir würden hier auch gerne eine Art DIP anwenden. Robert C. Martin besteht auf der Tatsache, dass diese Schicht in erster Linie geschäftsabhängig ist (was auch immer das bedeutet) und daher sind die Prinzipien ein wenig anders: Stabile-Abhängigkeiten-Prinzip und Stabile-Abstraktions-Prinzip (siehe Martins Prinzip und Praxis)
Nun sollten Sie auch die Prinzipien der Software-Entwicklung betonen, die Sie nur anwenden sollten, wenn Sie das Problem lösen müssen, das sie lösen. Solange Sie das Problem nicht haben, verwenden Sie sie nicht.
Auf Klassenebene sollten Sie den DIP verwenden, wenn Sie gute Gründe haben zu glauben, dass Ihr Protokollierungsmechanismus von mehreren Klassen implementiert wird. Wenn Sie der Meinung sind, dass es vorerst nur einen Logging Mechanim geben wird, dann ist es vollkommen in Ordnung, den DIP zu verwenden, da es kein Problem zu lösen gibt.
Nun sollte die gleiche Auswahl auf der Paketebene getroffen werden. Der Leitfaden für Ihre Verpackungsauswahl ist jedoch die Bereitstellung. Hier:
%Vor%Wie auch immer, diese Entscheidung ist meist geschäftsabhängig. Denken Sie auch daran, dass die Verpackung von unten nach oben erfolgen sollte: Erstellen Sie nur ein neues Paket, wenn Sie viele Klassen haben, die Sie organisieren möchten. Bis Sie nicht so viele Klassen haben, versuchen Sie nicht, früh Entscheidungen zu treffen, weil Sie fast sicher falsch liegen werden.
Tags und Links dependencies c++ deployment modularity dip-principle