[iOS Best Practices] Controller + UITableViewDelegate+Data

  • Créateur du sujet Créateur du sujet Rez2a
  • Date de début Date de début

Rez2a

Membre expert
Club iGen
4 Décembre 2008
1 056
123
38
Paris
Hello et désolé pour le titre du thread qui ne tient pas en entier (vous aurez compris que le dernier mot était DataSource),

je m'interrogeais sur un truc en jetant un coup d'oeil dans les docs d'Apple (dans lesquelles j'ai pas entièrement confiance, mais bref).

Ça fait quelques temps que je développe sur iOS, et quand il s'agit de foutre des UITableView et des UIViewController associés, j'ai pris depuis le début la peut-être mauvaise habitude d'implémenter les protocoles UITableViewDelegate et UITableViewDataSource dans le même controller.

Or j'ai le souvenir d'avoir vu tatouille, y a pas très longtemps, dire que c'était une super mauvaise pratique de procéder comme ça. En même temps, je me doute que si les deux protocoles sont dissociés, c'est évidemment qu'il y a moyen d'avoir un UIViewController implémentant UITableViewDelegate et une classe indépendante pour gérer ce qui touche au modèle avec UITableViewDataSource.

Le problème, c'est que les samples d'Apple fournis dans la doc ne se gênent pas pour laisser penser qu'il est conseillé d'implémenter les deux protocoles dans un même controller (et d'ailleurs, si je dis pas de connerie, UITableViewController implémente les deux par défaut). Et j'avoue qu'ayant démarré mon apprentissage en partie avec les docs d'Apple, j'ai pas cherché à voir plus loin, c'était logique de définir les méthodes de ces deux protocoles dans un même controller.

Donc ça m'aurait intéressé de savoir si beaucoup de gens procédaient de la même façon, ou si il y avait beaucoup de partisans du Delegate dans un controller et du DataSource autre part, histoire de voir dans quels cas l'une ou l'autre méthode était la meilleure.
 
:D j'ai deja exprimé mon opinion, imagine tu as un datasource relié a serveur distant et qui gere des caches locaux et peut faire bon nombre d'operations comme le trie, clarification

imagine un UIDelegate attaché aux événements de ton datasource qui peut changer les cells suivant le modele
implemente ce genre de truc dans un fichier et tu finis avec du caca en barre a 10000 lignes complétement bogué et unchangeable ce qu'on appele du code moisi du kuk écrit par un brantamouille.

Apple ne fait que des exemples rapides ce ne sont que des exemples pas ce que tu es supposé faire, face a un probleme donné, et de plus c'est tout le principe de l'objet une class pour un metier des factory objects pour ses employées, un controller est fait pour controller pas implementer
 
Dernière édition: