[PYTHON] Veranschaulichen Sie Klassenabhängigkeiten in einem Xcode-Projekt

Wenn Sie eine ungefähre Vorstellung vom Gesamtdesign eines Projekts erhalten möchten, das Sie von einer anderen Person geerbt haben, wenn Sie nur einen Teil einer großen Bibliothek extrahieren und verwenden möchten oder wenn Sie komplizierten Code umgestalten möchten, gibt es Klassenabhängigkeiten im Projekt. Ich denke, es gibt viele Situationen, in denen es nützlich ist, einen Panoramablick zu haben.

Mit einem Skript namens objc_dep können Sie mit einem einzigen Befehl ein Diagramm erstellen, das die Abhängigkeiten von Klassen in einem Xcode-Projekt zeigt, wie unten gezeigt.

Ich werde vorstellen, wie dieses Skript verwendet wird und wie die generierte Abbildung gelesen wird.

So führen Sie das Skript aus

Wenn Sie es von der folgenden URL herunterladen und entpacken, finden Sie eine Datei mit dem Namen objc_dep.py.

https://github.com/nst/objc_dep

Platzieren Sie das Skript an einem geeigneten Ort und führen Sie es wie folgt vom Terminal aus aus.

$ python objc_dep.py {Projektpfad}> {Name der Ausgabedatei} .dot

Wenn Sie beispielsweise einen Projektordner namens Demo direkt unter Ihrem Haus haben und mit dem Dateinamen demo.dot ausgeben möchten,

$ python objc_dep.py ~/Demo > demo.dot

Es wird zum Befehl.

Abhängigkeitsdiagramm anzeigen

Die ausgegebene DOT-Datei kann mit einer Anwendung namens Graphviz oder Omnigraffle angezeigt werden. (Omnigraffle ist eine etablierte Software zur Diagrammerstellung, die jedoch viel kostet. Wenn Sie also vorerst objc_dep ausprobieren möchten, empfehle ich Open Source Graphviz.)

Lesen des Abhängigkeitsdiagramms

Hier habe ich versucht, die Abhängigkeit der Beispielanwendung "Hackbook" auszugeben, die mit dem "Facebook iOS SDK" geliefert wird.

In der Ausgabe sehen Sie Orte, die durch blaue Pfeile verbunden sind.

Laut den Kommentaren im Quellcode scheint es beim "gegenseitigen Importieren" durch einen blauen Pfeil verbunden zu sein.

Unter dem Gesichtspunkt der Code-Wartbarkeit möchte ich die gegenseitige Abhängigkeit der Klassen so weit wie möglich vermeiden. Wenn ein blauer Pfeil vorhanden ist, kann dies eine Anleitung für das Refactoring sein, z. B. die Verwendung eines Protokolls, um zu prüfen, ob direkte Verweise nur aus einer Richtung möglich sind.

Auch wenn es in diesem Beispiel nicht angezeigt wurde, wird möglicherweise ein roter Pfeil angezeigt.

Der rote Pfeil bedeutet Import aus der .pch-Datei.

Aus .pch-Dateien importierte Header werden von allen Klassen referenziert (der Referenzpfeil wird nicht gezeichnet), daher wird er wahrscheinlich auf diese Weise verwendet.

Suchen Sie erneut nach unnötigen Abhängigkeiten, z. B. Importieren mit .pch, aber auch Importieren mit einzelnen Klassen, Importieren von Klassen, die nicht mit .pch importiert werden sollen usw. Es wird eine Richtlinie sein.

Auch in diesem Beispiel nicht gezeigt, werden die Kategorien aus dem Abhängigkeitsdiagramm herausgeschnitten (wenn sie nicht von anderen Klassen abhängig sind) und in der oberen rechten Ecke aufgelistet. Kategorien sind von Natur aus kein Designproblem, selbst wenn sie von vielen Dateien referenziert werden. Es scheint also, dass die Spezifikationen so gestaltet sind, dass die Figur nicht unordentlich wird.