Illustrer les dépendances de classe dans un projet Xcode

Si vous souhaitez avoir une idée approximative de la conception globale d'un projet hérité d'une autre personne, si vous souhaitez extraire et n'utiliser qu'une partie d'une grande bibliothèque, ou si vous souhaitez refactoriser du code compliqué, il existe des dépendances de classe dans le projet. Je pense qu'il existe de nombreuses situations où il est utile d'avoir une vue panoramique.

À l'aide d'un script appelé objc_dep, vous pouvez générer un diagramme montrant les dépendances des classes dans un projet Xcode avec une seule commande, comme indiqué ci-dessous.

Je vais vous présenter comment utiliser ce script et comment lire la figure générée.

Comment exécuter le script

Si vous le téléchargez à partir de l'URL suivante et que vous le décompressez, vous trouverez un fichier appelé objc_dep.py.

https://github.com/nst/objc_dep

Placez le script dans un emplacement approprié et exécutez-le depuis le terminal comme suit.

$ python objc_dep.py {chemin du projet}> {nom du fichier de sortie} .dot

Par exemple, si vous avez un dossier de projet appelé Demo directement sous votre maison et que vous souhaitez sortir avec le nom de fichier demo.dot,

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

Cela devient la commande.

Afficher le diagramme de dépendance

Le fichier .dot de sortie peut être visualisé avec une application appelée Graphviz ou Omnigraffle. (Omnigraffle est un logiciel de création de diagrammes bien établi, mais il coûte cher, donc si vous voulez essayer objc_dep pour le moment, je recommande l'open source Graphviz.)

Comment lire le diagramme de dépendances

Ici, j'ai essayé de sortir la dépendance de l'exemple d'application "Hackbook" fourni avec le "Facebook iOS SDK".

En regardant la figure de sortie, il y a des endroits qui sont reliés par des flèches bleues.

Selon les commentaires dans le code source, il semble être relié par une flèche bleue lors de "l'importation les uns des autres".

Du point de vue de la maintenabilité du code, je voudrais éviter autant que possible l'interdépendance des classes. Si une flèche bleue est présente, elle peut être un guide pour la refactorisation, comme l'utilisation d'un protocole pour déterminer si les références directes ne peuvent être faites que dans une seule direction.

De plus, bien qu'elle n'apparaisse pas dans cet exemple, une flèche rouge peut apparaître.

La flèche rouge signifie importer depuis le fichier .pch.

Les en-têtes importés à partir de fichiers .pch sont référencés par toutes les classes (la flèche de référence n'est pas dessinée), il est donc probable que ce soit le cas.

Encore une fois, vérifiez les dépendances inutiles, telles que l'importation avec .pch mais aussi l'importation avec des classes individuelles, l'importation de classes qui ne doivent pas être importées avec .pch, etc. Ce sera une ligne directrice.

Également non illustrées dans cet exemple, les catégories sont découpées dans le diagramme de dépendances (si elles ne dépendent pas d'autres classes) et répertoriées dans le coin supérieur droit. De par leur nature même, les catégories ne sont pas un problème de conception même si elles sont référencées par de nombreux fichiers, il semble donc que les spécifications sont conçues de manière à ce que le chiffre ne soit pas compliqué.