60 votes

Pourquoi utiliser un pointeur faible pour la délégation?

Je ne comprends pas pourquoi il est bon de définir un délégué à la faiblesse de l'pointeur :

@property (nonatomic,weak) id delegate;

Je ne peux pas comprendre pourquoi il n'est pas nécessaire de maintenir une référence au délégué... je ne veux pas l'objet que j'utilise en tant que délégué à être libéré... donc, je préfère utiliser une référence forte pas un faible!

Dans de nombreux cas, le délégué est le même objet sur lequel l'instance de ma classe sera créée, dans ce cas, la création d'une référence faible serait une excellente solution pour éviter de conserver cycle... mais si je choisis un tout autre objet que le délégué ?

J'ai cherché d'autres questions sur stack overflow, mais je ne peux pas trouver quelque chose qui peut m'aider à bien comprendre cette situation.

92voto

Barry Wark Points 73462

La raison que les objets faiblement conserver leurs délégués est d'éviter de conserver des cycles. Imaginez le scénario suivant: objet a crée b et de la conserve, puis définit lui-même comme bs'délégué. a est libéré par son propriétaire, laissant conserver un cycle contenant de l' a et b. C'est en fait un scénario très commun. Envisager une-vue-contrôleur qui possède un point de vue et les actes comme cette vue de son délégué. Dans ce cas, le point de vue ne devrait pas conserver le contrôleur comme une mater de la bonne architecture MVC et pour éviter de conserver des cycles.

26voto

kocodude Points 303

Bien conserver les cycles sont une préoccupation valable, le raisonnement pour une référence faible est plus liée à apple de point de vue sur la façon d'utiliser la délégation modèle avec uikit et d'autres éléments de la boîte qui est expliqué ici:

http://developer.apple.com/library/IOs/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html

Plus précisément: "La principale valeur de la délégation, c'est qu'il vous permet de personnaliser le comportement de plusieurs objets dans un seul objet."

Si le délégué traite de la gestion des tâches déléguées de plusieurs objets, ces objets n'ont pas besoin de conserver le délégué et ne doit pas porter la responsabilité de dealllocating le délégué qu'il pourrait être utilisé par d'autres objets. La faiblesse de référence applique le concept de la gestion du délégué n'est pas le delegators responsabilité.

Un exemple en objective-c est un un délégué être utilisé pour de multiples vues de table, comme lors de l'utilisation d'une table et d'un searchdisplaycontroller avec un uisearchbar. Pommes exemples d'utiliser le contrôleur en tant que délégué, mais le raisonnement tient toujours lors de l'utilisation d'un délégué personnalisé pour à la fois la principale vue de la table et le tableau de résultats pour votre recherche. Que délégué personnalisé serait susceptible d'être retenu par votre contrôleur afin d'être à la fois des vues de table.

C'est fondamentalement différente de la délégation de base modèle dont il est fait référence dans d'autres langues où le délégué est souvent créé par le délégataire et chaque instance peut gérer son propre instance de délégué.

18voto

awfullyjohn Points 1607

C'est pour éviter de conserver des cycles. Apple propose un guide d'information sur les avancées de la gestion de la mémoire expliquant la situation et la meilleure façon de traiter avec elle. Dans l'ARC, ils sont maintenant connus comme forte des cycles de référence, qui sont expliquées dans la Transition à l'ARC Notes de Version.

Auparavant, vous définissez une propriété pour un délégué de ce genre,

@property (nonatomic, assign) id delegate;

Mais dans l'ARC, vous pouvez le définir ainsi,

@property (nonatomic, unsafe_unretained) id delegate;

Ou, par exemple, si vous avez un protocole nommé <MyObjectDelegate>, vous pouvez également définir le délégué de cette façon,

@property (nonatomic, weak) id <MyObjectDelegate> delegate;

En d'autres termes, dans l'ARC si vous avez un protocole, vous pouvez déclarer un délégué weak. Sinon, unsafe_unretained.

3voto

Jason Points 11

Comme une pratique courante, si nous avons deux objets ayant des références les uns avec les autres, nous faire de "l'enfant" objet "parent-enfant" relation d'une référence faible.
Pour la délégation des modèles dans iOS, le délégué de l'objet est le parent, car il n'est pas nécessaire pour le délégué de l'appelant exister sans le délégué de l'objet. Par exemple, vous avez une phrase de l'objet avec l'objet delegate pour la méthode sentenceShouldEnd. Votre paragraphe de l'objet est le délégué de l'objet pour votre phrase de l'objet. Évidemment, le point objet est en fait la mère, et dans votre phrase de l'objet que vous devez garder votre délégué comme une référence faible.
De votre point de vous attribuer le délégué de l'auto, votre compréhension est erronée. Nous ne devons jamais céder délégué à lui-même. Pourquoi vous achetez votre billet, vous-même si vous vous sentez qu'il est nécessaire d'engager un agent pour acheter un ticket pour vous? Vous dites deux concepts totalement différents. Lorsque vous définissez un délégué de l'objet de la propriété, il est utilisé une référence faible dans l'objet qu'il est défini dans(disons Un, c'est à dire le délégué de l'objet est une propriété d'Une). Le délégué est attribué lors de l'initialisation d'Un(disons B), il est alors probable que vous pouvez assigner A. délégué à soi-même, qui est acturally B. Vous voyez la relation parent-enfant ici?? Vous alloue de la mémoire pour Une en B. Vous tenez dans B. Un n'existe pas sans B. Vous n'êtes pas de l'affectation de la déléguer à Un!!!!

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X