izostar a dit:Oui, c'est ce que je me disais, mais je trouve pas cela logique. On y entre du texte aussi... (mais je vais pas remttre en cause la conception des classes, j'ai que 5 jours de cocoa...).
Saches une chose importante. C'est que quand tu fais du cocoa, oublies ce que tu as fait auparavant et pense encore et toujours objet. le fait de pouoir mettre du texte dans un objet NSTextView ou un objet NSTextField, ne signifie en aucun cas que cela est fait en utilisant une même méthode setStringValue.
Développer en objet c'est faire ceci : J'ai un problème à résoudre, je le divise en tâches puis je me dis que chaque tâche sera exécutée par un objet. Seulement comme je fais du cocoa, mes objets je ne les invente pas je dois les créés à partir d'objets de2 Framework de Cocoa. Je vais donc dans les Frameworks Cocoa qui sont Foundation Kit et Application Kit pour faire 'mes courses' et trouver des objets prédéfinis. C'est exactement comme si tu bâtissais une maison. tu en fais le plan, les agencements etc. Le tout sur papier et tu fais tes courses en allant chercher les briques, des portes que tu assembles. C'est aussi comme un jeu de leggo.
D'ailleurs une application Cocoa n'est ni plus ni moins composée d'objets qui interagissent les uns par rapport aux autres en s'envoyant des messages.
La notion de délégation permet à deux objets qui 'se connaissent' (car l'un est délégué de l'autre) de communiquer.
La notion de Notification par contre permet à deux objets qui ne savent rien l'un de l'autre de se communiquer. Pour cela il passent par un objet intermédiaire appelé NSNotificationCenter. Dans chaque appli Cocoa, en plus des objets de l'application, il existe également d'autres objets appelés default objects du runtime Cocoa qui fonctionnent pendant le déroulement de l'application. Le NotificationCenter en fait partie. L'instruction NSNotificationCenter *myNotif = [NSNotificationCenter defaultCenter] permet de le designer par le nom myNotif.