Plus sur dealloc

Je ne m'attendais vraiment pas à la coup d'envoi d'une telle shitstorm hier avec mon message dealloc. Quelques personnes m'ont accusé de prosélytisme de la pratique de Ivars nil'ing, au moins pour code de déblocage. Peut-être que j'ai fait, mais ma véritable intention était de partager les raisons pour lesquelles vous pourriez choisir une approche plutôt qu'une autre, pour ne pas dire «vous devriez faire de cette façon." J'ai surtout écrit le message de blog pour m'assurer que j'avais ma tête complètement enroulé autour du débat parce qu'il était venu lors de la révision du début de développement iPhone.

Daniel Jalkut répondu avec une très lucides écriture jusqu'à qui représente l'un des points de vue communs sur ce sujet. Ce point de vue pourrait se résumer en "crash, bébé, crash". Si vous voulez trouver des bugs, la meilleure chose que vous pouvez faire est de plantage quand ils se produisent, de cette façon vous savez qu'il ya un problème et de savoir pour le chercher. Ce n'est pas une idée nouvelle. Je crois me souvenir d'une extension du système de retour à l'ancien système Mac Système 6 ou 7 jours qui effectivement causer votre système d'accident si votre application a fait une chose certaine mauvaise, même si cette chose mauvaise ne pas causer de problèmes notables dans votre app . Je ne me souviens pas honnêtement les détails, mais il avait quelque chose à voir avec le mécanisme de piégeage, je pense (que quelqu'un sait ce que je parle?). Bien sûr, Apple n'a pas expédier cette extension aux non-développeurs.

Ce qui rend ce un argument difficile est que Daniel a parfaitement raison ... parfois. Il existe des scénarios où les planter est beaucoup mieux que, disons, perte de données ou l'intégrité des données. Les règles générales sont toujours problématique, mais si je vois son point, je suis coller avec "ne pas s'écraser sur les clients" étant une bonne règle générale ... sauf quand il n'est pas.

Dans l'intérêt de la divulgation complète, il ya en fait un modèle dealloc tiers, mais une lointaine troisième en popularité, mais il est définitivement devenu plus populaire que quand j'ai la tête de celui-ci. Dans cette approche, vous cédez votre variable d'instance à une variable pile locale, alors nul la variable d'instance before le relâcher, comme ceci:

- (void)dealloc {     id fooTemp = foo;     foo = nil;     [fooTemp release]; } 

Dans l'approche presse-alors-nul, dès que vous relâchez, il ya une petite fenêtre entre la libération et l'assignation de néant où, dans le code multithread, le pointeur invalide pourrait encore être théoriquement être utilisés. Cette approche évite ce problème en nil'ing premier. Ce point de vue représente l'extrémité opposée du spectre de celui déclaré Daniel. Dans cette approche, votre but est de coder de manière défensive et ne laissez jamais votre accident app si vous pouvez l'aider, même dans le développement. Si vous êtes un programmeur prudent et croient dans le Tao de la programmation défensive, alors là vous allez - c'est votre approche de dealloc.

Pour moi, personnellement (avertissement - je suis sur le point de formuler un avis) je ne peux pas justifier le code supplémentaire et le temps de l'approche défensive. C'est un traitement préventif d'un problème si rare que c'est presque ridicule que cette discussion est encore passe. J'ai été écrit en Objective-C depuis 1999 et je n'ai vu qu'une seule fois un scénario où l'approche dealloc aurait fait une différence dans le comportement réel de la demande, et qui a été créé un scénario pour un exercice de débogage dans un atelier , alors nous sommes vraiment couper les cheveux ici.

Alors, voici mon dernier mot sur dealloc:

1. Si vous avez déjà une opinion bien arrêtée sur celle à utiliser pour le type de codage de vous le faites, utilisez celui-là. Si ce n'est pas ...
2. Si vous préférez que les bugs toujours planter votre application si vous savez à leur sujet, utilisez le traditionnel communiqué seule approche
3. Si vous préférez ne pas se bloquer si vous pouvez l'aider et préfèrent trouver des bugs en utilisant d'autres moyens, utilisez la nouvelle approche
4. Si vous voulez que votre application à planter pour vous, mais pas vos clients, utilisez le MCRelease () macro ou utiliser # si debug directives pré-processeur

Ce qui est important est que vous comprenez les avantages et les problèmes des différentes approches, et non que vous utilisez le même que celui que je fais (ou Daniel ne, ou n'importe qui d'autre).

Après tout, vous êtes celui qui doit vivre avec les conséquences de votre décision.