Dynamic Binding : différence entre appel de fonction et envoi de messages
colionel
Membre
Salut,
En relisant la doc je tombe toujours sur des trucs super interessants mais que j'ai du mal a bien comprendre. En particulier au début de "The Objective-C Programming Language", il y a un chapitre sur le concept de dynamic bindings qui explique l'interet de l'envoi de messages par rapport à l'appel de fonction.
J'ai trouvé ce passage hyper intéressant :
Mais là j'ai vraiment du mal à comprendre comment mettre ça en pratique :
- Déjà je ne vois pas trop l'intérêt par rapport à de la délégation pour répondre à ce cas de figure (avec un protocol qui définit des méthodes copy/cut/paste).
- Ensuite si je voulais rajouter du copier coller sur un objet custom de mon appli, je serais passer par UIPasteboard.
Bref dans tout les cas j'ai du mal à visualiser concrètement l'intérêt du concept de dynamic binding sur cet exemple ?
Merci pour vos lumières,
Vincent.
En relisant la doc je tombe toujours sur des trucs super interessants mais que j'ai du mal a bien comprendre. En particulier au début de "The Objective-C Programming Language", il y a un chapitre sur le concept de dynamic bindings qui explique l'interet de l'envoi de messages par rapport à l'appel de fonction.
J'ai trouvé ce passage hyper intéressant :
When executing code based upon the Application Kit, for example, users determine which objects receive messages from menu commands like Cut, Copy, and Paste. The message goes to whatever object controls the current selection. An object that displays text would react to a copy message differently from an object that displays scanned images. An object that represents a set of shapes would respond differently from a Rectangle. Since messages don't select methods (methods aren't bound to messages) until runtime, these differences are isolated in the methods that respond to the message. The code that sends the message doesn't have to be concerned with them; it doesn't even have to enumerate the possibilities. Each application can invent its own objects that respond in their own way to copy messages
Mais là j'ai vraiment du mal à comprendre comment mettre ça en pratique :
- Déjà je ne vois pas trop l'intérêt par rapport à de la délégation pour répondre à ce cas de figure (avec un protocol qui définit des méthodes copy/cut/paste).
- Ensuite si je voulais rajouter du copier coller sur un objet custom de mon appli, je serais passer par UIPasteboard.
Bref dans tout les cas j'ai du mal à visualiser concrètement l'intérêt du concept de dynamic binding sur cet exemple ?
Merci pour vos lumières,
Vincent.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Cela permet également de faire de l'introspection en demandant dynamiquement au runtime à un objet ce qu'il sait faire, à implémenter le KVC simplement grâce aux conventions de nommage, de gérer très symplement les mécanismes de plugins (charger un Bundle dynamiquement au runtime), etc.
L'exemple est pour le Mac, pas pour iOS qui n'a pas vraiment de notion de sélection courante ou de "focus" sur un contrôle.
Il existe un mécanisme astucieux, qui permet d'envoyer des messages à "nil". Dans ce cas, l'AppKit descend la hiérarchie des vues jusqu'à trouver un contrôle qui répond à -[copy:]. L'objet qui recevra le message n'est donc pas connu à la compilation.
Un meilleur exemple est celui de NSInvocation: cette classe permet de stocker un message pour plus tard.
L'Undo Manager se base dessus pour annuler une action; en pratique, le message qui permet de revenir à l'état précédent (et ses paramètres), sont stockés dans une NSInvocation. Il est impossible de coder une telle classe sans le dynamic binding.
Il y a d'autres exemples, comme NSProxy. Si ça t'intéresse, je te conseille la lecture de "Les Design Patterns De Cocoa" chez Pearson, ça en parle en détails.
Quand on vient du java par ex ça parait assez inutile (et dangereux) qu'un objet qu'on a typé NSString a la compilation puisse en fait devenir un NSArray au runtime, je vois un peu mieux à quoi sert cette souplesse.