À quel point, en théorie, est-ce que chaque classe inclurait toutes les autres classes?

Question

Imaginez une application iPhone avec 30 classes. Chaque classe doit interagir avec les autres, de sorte que chaque classe comprend 29 autres classes + cadre de la fondation.

Je veux comprendre ce qui se passe exactement en incluant une classe. Est-ce que cela duplique la taille en mémoire pour cette classe dans l'application? Est-ce dangereux pour l'empreinte de la mémoire et les performances sur l'iPhone? Peut-être que quelqu'un le sait en détail et peut expliquer.

Veuillez manquer que ce ne serait pas une bonne architecture. C'est une question hypothétique sur ce que «inclure» fait à la mémoire et à la performance.

Answer 1

Il existe une différence entre inclure et instancier. Si chaque classe tente d'instancier l'autre, alors oui c'est très mauvais. Bien que, si vous fournissez simplement une référence au fichier afin que n'importe quelle classe puisse être instanciée de n'importe où, le seul problème que vous rencontrerez probablement est celui des mauvais chemins si vous essayez de changer les choses. Changer le nom d'un fichier (ou d'une classe), par exemple, signifie que vous devez maintenant aller rectifier 29 autres mauvaises références à ce chemin. Pour autant que je sache, le simple fait d'inclure le fichier (au moins dans les langues que je connais) n'affectera pas vos performances.

Answer 2

Habituellement, l'inclusion et la portée, l'orientation de l'objet, etc., n'est qu'un utilitaire pour le programmeur. Une illusion d'ordre si vous voulez. Au niveau du code machine, vous pouvez accéder à n'importe quelle variable de votre processus partout. Le fait que vous ayez à inclure des en-têtes utilisés ailleurs dans votre programme est seulement un moyen que les créateurs de langage utilisent pour limiter les choses auxquelles vous devez penser, éliminer les doublons etc. et que le compilateur peut vous aider à vérifier que "description" du programme fonctionne bien.

Vous ne faites que grossir votre exécutable si vous liez des éléments. Comme Evernoob l'a laissé entendre, si vous produisez beaucoup d'instances, etc., le simple fait de faire connaître les types et les définitions à d'autres classes ne devrait pas causer de problèmes de performance au moment de l'exécution, mais augmentera généralement le temps de compilation.

Answer 3

Le seul cas où vous pourriez être confronté à un hit de performance est au moment de la compilation. En utilisant #import "MyClass.h" au lieu de @class MyClass dans l'en-tête d'une classe, il sera recompilé lorsque l'interface de MyClass sera modifiée. Cela ajoutera un peu à votre temps total de compilation, ce qui peut s'ajouter à un grand projet.

EDIT (8/29/2009): J'ai changé #include à #import dans la réponse ci-dessus, car il est utilisé dans ObjC pour empêcher les reprises répétées d'en-têtes.

Answer 4

En général, essayer de réduire les dépendances est plus important que de ne pas avoir à changer une tonne de code quand une classe change.

Simplement inclure beaucoup de fichiers, ce n'est pas nécessairement mauvais - tout ce qu'il ferait est d'augmenter le temps de compilation mais l'augmentation ne serait pas vraiment perceptible jusqu'à ce que vous arriviez à des centaines de fichiers (si cela).

Autre chose à garder à l'esprit est qu'il y a une différence entre inclure à partir d'un en-tête par rapport à un fichier de classe. Si vous incluez une définition de classe à partir d'un en-tête qui contient à son tour un en-tête, vous disposez d'une référence circulaire et vous devez déclarer l'une des références de classe en tant que classe transférée avec la directive @class.En fait, la norme est théoriquement d'utiliser "@class" dans le fichier d'en-tête et "@import" dans l'implémentation, mais généralement, vous ne rencontrez pas de classes ayant des références les unes pour les autres, donC#import fonctionne aussi bien dans l'en-tête. et est un peu moins typé.