Quelle est la différence entre la source de données et le délégué?
J'ai une question fondamentale liée aux modèles de conception des frameworks Cocoa.
Quelle est la différence entre le délégué et la source de données?
Les deux pourraient utiliser @protocols, mais certaines classes ou frameworks utilisent delegate, et d'autres utilisent datasource.
Tout ce que je peux comprendre de UI/NSTableView est le delegate répond aux événements liés à l'interface utilisateur, tandis que le datasource est purement lié aux données. Mais, je ne connais aucune implémentation de source de données en dehors des classes d'interface utilisateur de Cocoa.
Remarque:
- Le délégué que j'ai mentionné dans cette question n'est pas toujours lié aux événements de l'interface utilisateur.
- La question sur la source de données a été répondue.
Les modèles de délégué et de source de données sont largement indépendants et orthogonaux:
Le modèle de délégué est très courant dans Cocoa et autorise un délégué (toute instance implémentant le protocole de délégué informel avant OS X 10.6, ou le délégué formel @protocol dans 10.6 et versions ultérieures) pour modifier le comportement d'une instance d'objet. Ce modèle est souvent utilisé au lieu de sous-classer: au lieu de sous-classer une classe pour changer son comportement, vous fournissez un délégué qui répond aux méthodes appropriées. Les classes qui utilisent des délégués envoient des messages à leur délégué lors d'événements contractuels. L'API entre la classe et le délégué est définie par la classe et est différente pour chaque classe qui utilise le modèle, mais l'API se compose généralement de messages demandant au délégué comment gérer un événement particulier. Un avantage du modèle de délégué par rapport au sous-classement est qu'une classe peut implémenter plusieurs protocoles de délégué, permettant à ses instances d'agir en tant que délégué pour plusieurs classes. De même, une instance d'objet peut être le délégué de plusieurs autres objets (par conséquent, la plupart des API déléguées transmettent l'objet comme premier argument à chaque message de l'API). Le modèle de délégué n'est pas aussi courant dans d'autres cadres d'interface utilisateur (bien que Qt utilise le modèle de délégué dans son modèle/vue), et est pas le même que les délégués .Net/CLR qui sont essentiellement des fonctions typées pointeurs.
Le modèle de source de données est souvent utilisé par les sous-classes NSView dans Cocoa qui ont des données d'état complexes telles que NSBrowser, NSTableView, NSOutlineView, etc. Le protocole de source de données définit une API qui installe des instances de ces classes (et d'autres) peut utiliser pour obtenir les données à afficher dans la vue. Bien que les architectures NSController et Cocoa Bindings aient remplacé de nombreuses utilisations du modèle de source de données, il est toujours courant et très puissant. Comme le modèle de délégué décrit ci-dessus, une partie de sa puissance provient du fait qu'un objet peut agir comme source de données pour plusieurs instances utilisant des sources de données (et peut-être même des instances de plusieurs classes qui ont différents protocoles de source de données). Le modèle de source de données est couramment utilisé dans d'autres cadres d'interface utilisateur, tels que Qt (dans le cadre Modèle/Vue où le modèle est analogue à la source de données) et WPF/Silverlight (où la source de données peut être plus étroitement analogue au modèle de vue ).
La source de données fournit les données, le délégué fournit le comportement.
Dans MVC , la source de données est dans la couche modèle et le délégué est dans la couche contrôle.
En fait, après réflexion, la source de données est généralement un contrôleur plus bas, plus proche du modèle. Je ne pense pas avoir jamais utilisé un objet modèle comme source de données.
Avant de répondre à la question, vous devez mieux comprendre le modèle de conception de la délégation: Permettez-moi de commencer par une question:
Par défaut, une TableView est comme ceci:
Comment une UITableView sait-elle combien de cellules présenter? que présenter dans chaque cellule?
- En soi, il ne sait pas.
- Il demande à une autre classe de informer de lui-même le nombre de cellules et la cellule à retourner (quelle image de cellule, quel titre de cellule, quel sous-titre de cellule, etc.) lui-même. Vous voyez généralement une tableView (classe délégante) à l'intérieur d'un ViewController (classe déléguée)
- Ce concept d'une classe demandant une autre est connu comme délégation!
Maintenant que vous savez ce qu'est la Délégation, pour répondre à la vraie question du PO:
C'est surtout une ÉNORME question de différences sémantiques.
Si vous ne devez utiliser (pas pour créer votre propre protocole) les délégués et les sources de données de la fondation, alors cela n'a pas vraiment d'importance pour vous. Cependant, si vous avez l'intention d'écrire des protocoles personnalisés, les comprendre vous aiderait à mieux écrire (et avec une lecture plus importante, réfracteur).
Du point de vue d'un développeur, ils traitent tous les deux de l'interaction entre la classe delegat - ing et la classe delegate.
Une source de données est presque identique à un délégué. La différence réside dans la relation avec l'objet délégué. Au lieu d'être un contrôle délégué de l'interface utilisateur, une source de données est un contrôle délégué des données. L'objet délégué, généralement un objet de vue tel qu'une vue de table, contient une référence à sa source de données et lui demande parfois les données qu'il doit afficher. Une source de données, comme un délégué, doit adopter un protocole et mettre en œuvre au minimum les méthodes requises de ce protocole. Les sources de données sont responsables de la gestion de la mémoire des objets de modèle qu'elles donnent à la vue délégante.
En termes de Layman:
DataSource traite principalement de ce qui et le fait généralement c'est quelque chose lors de l'initialisation. Le délégué traite principalement de comment et vous alimente certains paramètres pour donner une certaine comportement, c.-à-d. si l'utilisateur a cliqué dessus ... que devrait-il se passer? s'ils glissaient ... que se passerait-il?
Comme exemple pour tableView:
DataSource
Qu'y a-t-il à l'intérieur? Quel type de cellule est-ce que je présente? cellForRowAtIndexPath.
Quel est le titre de la section? titleForHeaderInSection Combien de cellules sont-elles? numberOfRowsInSection Et donc vous avez généralement retour valeurs. Pour les délégués, il est plus courant d'être de type void.
Méthodes de source de données
func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell // return a cell ie UITableViewCell
func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int // return a number ie an Int
func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? // return the title ie a String
Méthodes déléguées
func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath)
func tableView(tableView: UITableView, willBeginEditingRowAtIndexPath indexPath: NSIndexPath)
func tableView(tableView: UITableView, willBeginEditingRowAtIndexPath indexPath: NSIndexPath)
J'ai évidemment choisi de manière sélective car certaines méthodes de source de données ne reviennent pas et certaines méthodes de délégué reviennent
Délégué
Que dois-je faire/quelle "forme de comportement" dois-je utiliser après avoir terminé l'affichage du pied de page, voulez-vous que je déclenche une alerte? didEndDisplayingFooterView
Vais-je avoir un type d'accessoire qui donne à la cellule des fonctionnalités supplémentaires? accessoryTypeForRowWithIndexPath
De mon point de vue, un DataSource est un objet qui ne sait pas où se trouvent les données, et donc vous devez les fournir. Tels que de dire à un objet combien d'éléments dans une colonne.
Un Delegate, qui est une partie que l'objet vous montre, doit être implémenté par votre classe, car l'objet sait où se trouvent les données, mais il ne sait pas comment les utiliser correctement.
Pour faire court:
Délégué se rapporte aux actions de l'interface utilisateur et de l'utilisateur contre les cellules et le tableau.
méthodes courantes: willSelectRow, didSelectRow, willDisplay, heightForRow, willBeginEditingAt
Data Source traite de l'édition, du remplissage et de l'affichage des données sur la table.
méthodes courantes canEditRowAt, commit, titleForHeaderInSection, cellForRowAt, numberOfSections, sectionIndexTitles
Les deux sont Protocol, maintenant l'intention principale de Protocol est de garder une pratique de codage universelle, ou la même pratique de codage pour tous (à ma connaissance). Supposons que je crée une tableView sans ITableViewDataSource & ITableViewDelegate, je créerais la tableView de telle manière que vous ne le feriez pas. C'est là que Protocol vient, Apple a créé un ensemble de règles ou protocol et tout le monde doit suivre cela. Maintenant DataSource & Délégué sont évidemment Protocol, en voyant le nom que vous pourriez comprendre DataSource traite quelque chose comme numberOfRowsInSection, - cellForRowAtIndexPath, numberOfSections de tableView où une sorte de données est prise/traitée, et Délégués sont didSelectRow, - willSelectRow, heightForRow etc de tableView où il est lié à une sorte de changement/action d'interface utilisateur. Donc, sa convention de dénomination juste rien d'hypothétique pour garder la tâche séparée. Comme @kubi l'a dit plus tôt: la source de données fournit les données, le délégué fournit le comportement.