Bonne question. 1. L'explication que j'ai apprise est la suivante : les notifications provoqueront des interférences. Par exemple, si vous souhaitez télécharger trois images A, B et C, et que le téléchargement de A est terminé, une notification sera envoyée et les endroits où se trouvent les images. B et C attendent des notifications et les recevront également, mais ce n'est pas nécessaire.
Je pense que ce problème peut être résolu. Ajoutez simplement l'identification correspondante à chaque tâche. Par exemple, dans le cas du téléchargement d'images ci-dessus, le nom de la notification est défini sur "loadImage_" + la dernière section de l'url. Et la notification peut préciser l'expéditeur
2. Je pense qu'il peut être utilisé avec désinvolture. L'utilisation d'un proxy présente certains avantages : le nom de la méthode du délégué est déjà défini, la définition de l'interface est claire et vous savez quels paramètres transmettre, ce qui est préférable pour le développement collaboratif ou la construction de roues. Les notifications s'appuient généralement sur les informations utilisateur pour transmettre les paramètres. Il s'agit d'un dictionnaire sans type spécifié. La structure des données à l'intérieur n'est pas sûre et n'est pas très claire.
3. En fait, je pense qu'il est préférable d'utiliser le bloc ou la fermeture.
Plusieurs délégués doivent être ajoutés au tableau, ce qui entraîne des références fortes et d'éventuels problèmes de référence circulaire.
Je pense que le bloc est plus amusant à écrire. Vous pouvez écrire le code de rappel à côté, comme télécharger des images,
var name:string = "xxx"
downloadImageWithCompleteHander:{
//回调后的逻辑可以直接写在这里
//可以直接使用这个临时变量name,因为block的copy性质
}
En ce qui concerne la délégation, vous devez écrire une autre méthode, surtout si certains paramètres doivent être transmis. Lorsque vous utilisez un délégué, vous devez transformer ces pages de variables temporaires en variables membres, sinon elles ne peuvent pas être utilisées entre les méthodes
Le dernier bloc a de bonnes propriétés d'isolation. Par exemple, utilisez une seule instance pour gérer tous les téléchargements d'images, en supposant qu'elle s'appelle LoadManager. Si vous utilisez plusieurs délégués, vous devez toujours faire la distinction entre les différentes tâches de téléchargement, car toutes les tâches de téléchargement vont à une seule chose, LoadManager, et il en existe de nombreuses. La liste des délégations contient des délégations pour différentes tâches de téléchargement, qu'il convient encore de distinguer. Mais en utilisant des blocs, ils peuvent être naturellement isolés. L'explication est plus compliquée, c'est-à-dire que les blocs sont imbriqués les uns dans les autres et isolés dès le début. Cela sera clair si vous regardez le code de SDWebImage.
Bonne question.
1. L'explication que j'ai apprise est la suivante : les notifications provoqueront des interférences. Par exemple, si vous souhaitez télécharger trois images A, B et C, et que le téléchargement de A est terminé, une notification sera envoyée et les endroits où se trouvent les images. B et C attendent des notifications et les recevront également, mais ce n'est pas nécessaire.
Je pense que ce problème peut être résolu. Ajoutez simplement l'identification correspondante à chaque tâche. Par exemple, dans le cas du téléchargement d'images ci-dessus, le nom de la notification est défini sur "loadImage_" + la dernière section de l'url. Et la notification peut préciser l'expéditeur
2. Je pense qu'il peut être utilisé avec désinvolture. L'utilisation d'un proxy présente certains avantages : le nom de la méthode du délégué est déjà défini, la définition de l'interface est claire et vous savez quels paramètres transmettre, ce qui est préférable pour le développement collaboratif ou la construction de roues. Les notifications s'appuient généralement sur les informations utilisateur pour transmettre les paramètres. Il s'agit d'un dictionnaire sans type spécifié. La structure des données à l'intérieur n'est pas sûre et n'est pas très claire.
3. En fait, je pense qu'il est préférable d'utiliser le bloc ou la fermeture.
Plusieurs délégués doivent être ajoutés au tableau, ce qui entraîne des références fortes et d'éventuels problèmes de référence circulaire.
Je pense que le bloc est plus amusant à écrire. Vous pouvez écrire le code de rappel à côté, comme télécharger des images,
En ce qui concerne la délégation, vous devez écrire une autre méthode, surtout si certains paramètres doivent être transmis. Lorsque vous utilisez un délégué, vous devez transformer ces pages de variables temporaires en variables membres, sinon elles ne peuvent pas être utilisées entre les méthodes
Le dernier bloc a de bonnes propriétés d'isolation.
Par exemple, utilisez une seule instance pour gérer tous les téléchargements d'images, en supposant qu'elle s'appelle LoadManager. Si vous utilisez plusieurs délégués, vous devez toujours faire la distinction entre les différentes tâches de téléchargement, car toutes les tâches de téléchargement vont à une seule chose, LoadManager, et il en existe de nombreuses. La liste des délégations contient des délégations pour différentes tâches de téléchargement, qu'il convient encore de distinguer. Mais en utilisant des blocs, ils peuvent être naturellement isolés. L'explication est plus compliquée, c'est-à-dire que les blocs sont imbriqués les uns dans les autres et isolés dès le début. Cela sera clair si vous regardez le code de SDWebImage.