iPhone: méthode statique vs sharedManager dans Objective-C

Question

J'ai un tas de fonctions qui retourne les UIViews couramment utilisées dans mon application, par ex.

+ (UIView *) getLikeRow:(CGRect) frame ofType:(LikeType) type 

Jusqu'à présent, je me sers de méthodes statiques pour cela, mais récemment, je aussi remarqué le concept sharedManager. Maintenant, je me demande si je devrais plutôt utiliser un sharedManager pour cela. Quelles sont les différences et les avantages/inconvénients de l'utilisation de méthodes statiques par rapport aux méthodes d'instance d'un singleton sharedManager?

Answer 1

Vous utilisez le modèle singleton/shared-managed lorsqu'il est important qu'une seule instance d'une classe soit active à tout moment. Par exemple, il est important qu'une application possède une et une seule instance de UIApplication. Vous voudriez deux instances de l'objet application car il serait impossible de les garder tous les deux dans le même état. NSFileManager utilise le modèle pour empêcher l'application d'avoir deux opérations de fichiers qui entrent en collision les unes avec les autres.

Faire valoir une instance unique lors de l'exécution est la seule raison valable d'utiliser le singleton/pattern géré partagé.

Dans votre cas, vous avez juste besoin d'un emplacement pratique pour ranger certaines méthodes de classes d'utilitaires qui n'ont pas besoin d'une instance réelle pour fonctionner. La meilleure façon de gérer cela est de créer une classe utilitaire regroupant toutes les méthodes de classe. Ensuite, utiliser les méthodes, vous envoyez juste le nom de classe comme ceci:

UIView *theView=[MyViewUtilityClass getLikeRow:aRect ofType:aType]; 

Cela provoque le MyViewUtilityClass d'appeler la méthode partout dans l'application sans avoir à initialiser un objet. C'est plus facile et plus propre que de garder une instance unique en vie. Si vous utilisez les méthodes utilitaires dans votre application, vous pouvez ajouter l'en-tête à l'en-tête universel .pch et toutes vos classes personnalisées obtiendront la classe d'utilitaire automatiquement. Toutefois, tout comme le modèle singleton, les méthodes de classes d'utilitaires peuvent vous inciter à devenir paresseux et à les surutiliser là où elles n'appartiennent pas vraiment. Surutilisés, ils commencent à faire en sorte que l'application ressemble à une collection C de fonctions indépendantes, non orientée objet et à l'ancienne. Cela brise l'encapsulation et la modularité et fait de votre programme un enchevêtrement de code procédural. Par conséquent, veillez à ne placer que les fonctions les plus génériques et les plus universelles dans la classe d'utilitaires. Si vous avez beaucoup de fonctions qui traitent d'une classe spécifique, comme une UIView et des sous-classes, alors vous devriez mettre les fonctions dans une catégorie sur cette classe.