Discussion :

[ProgMac]

Bonjour,

J'étudie actuellement la programmation Cocoa, et je bloque sur le principe de la délégation...
Je connais l'objective C, et je m'attaque au développement d'application Mac !
J'arrive à l'étude de la délégation mais là... je ne comprend pas, j'ai beau rechercher sur le net, dans des bouquins, je n'arrive pas à me faire une image de cette délégation !

Quelqu'un aurait-t-il des exemples qui puissent m'aider ? Ou un exemple pragmatique, pas forcément avec du code source, quelque chose qui puisse m'éclairer...
Je ne vois pas non plus l'intérêt, pourquoi créer des fonctions toute bêtes dont la classe ne fonctionnerait pas ?

Merci

[JeitEmgie]

La délégation permet justement de ne pas devoir sous-classer à-tout-va :
on confie à un objet tiers appartenant généralement à une taxonomie plus simple et toujours indépendante de celle à laquelle appartient l'objet qui délègue.

En confiant la réalisation de certaines tâches à un "delegate" qui respecte une certaine interface ("protocol"), on découple les fonctionnalités : on augmente la portabilité du code et on facilite les évolutions du code qui délègue.

Or le code qui délègue est généralement celui des frameworks qui constituent Cocoa : par ce mécanisme, le développeur d'application est abstrait des détails d'implémentation de ceux-ci et n'est pas tenté de réaliser du code dépendant des détails d'implémentation ou de la taxonomie de ses classes privées, et les développeurs des frameworks sont libres de faire les refactoring qu'ils jugent nécessaires sans risque de voir les applications des tiers devenir incompatibles du jour au lendemain : leur seule contrainte est que le refactoring doit continuer d'appeler le delegate selon les conventions prévues.
Par ailleurs, si vous obligez les développeurs à sous-classer, vous devez aussi documenter le fonctionnement interne des classes, ce qui est beaucoup plus lourd que de documenter un protocole…

D'autre part, peu importe la taxonomie à laquelle appartient le delegate à partir du moment où il respecte le protocole : donc le développeur d'application est libre d'utiliser ses propres taxonomies et les patterns d'implémentation qu'il désire, ce qui augmente aussi la ré-utilisation du code : le même delegate pouvant servir à plusieurs clients de classes différentes, sans lui, vous auriez eu besoin de plusieurs sous-classes avec duplication de code.