passage des données d'une instance à une autre
bofy
Membre
Bonjour
Plus ça va et plus j'arrive à faire de choses. Mais je n'ai toujours pas bien compris la logique de obj-C, et donc mes programmes sont des horreurs, même s'ils marchent.
Ma tendance de vieux programmeur C est de faire le maximum de modules, de libraries qui échangent entre eux via des passages d'arguments ou des globals.
La logique dite "objet" veut qu'on accède aux données des instances via des méthodes, pourquoi pas. Mais cela suppose que les instances soient instanciées au sein d'une même instance globale, non ? D'où des monstres de code face aux lutins du C.
Qui pourrait me proposer une façon d'organiser mon programme, sans parler du MVC pour lequel je suis en contact par ailleurs ? Et surtout merci de ne pas me renvoyer à Hillegass !
Plus ça va et plus j'arrive à faire de choses. Mais je n'ai toujours pas bien compris la logique de obj-C, et donc mes programmes sont des horreurs, même s'ils marchent.
Ma tendance de vieux programmeur C est de faire le maximum de modules, de libraries qui échangent entre eux via des passages d'arguments ou des globals.
La logique dite "objet" veut qu'on accède aux données des instances via des méthodes, pourquoi pas. Mais cela suppose que les instances soient instanciées au sein d'une même instance globale, non ? D'où des monstres de code face aux lutins du C.
Qui pourrait me proposer une façon d'organiser mon programme, sans parler du MVC pour lequel je suis en contact par ailleurs ? Et surtout merci de ne pas me renvoyer à Hillegass !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Lorsqu'a un moment tu as besoin d'un objet, tu le crées et tu regardes pas comment cet objet en question crée lui-même les choses dont il a besoin. Ensuite, tu peux éventuellement accéder à ces objets (en fait les variables d'instance), puis aux objets des objets, etc ... avec les accesseur.
Par exemple, si en Obj-C tu as un objet OCExemple appelé ex qui a pour variable d'instance une fenetre (classe NSWindow) et que tu veux récupérer la couleur d'arrière plan de la fenêtre, tu vas faire :
[[ex window] backgroundColor];
En C, avec des structures, tu aurais un truc equivalent, à savoir ex.window.backgroundColor (il est à noter que l'on a le droit de faire ca avec Objective-C 2, mais la n'est pas la question).
Tu peux aussi récupérer des instances grâce aux singleton (les variables globales version POO).
Si tu fais un trucs sans IB, la classe "maitre", qui va etre a la source de tout, ce sera une sous-classe de NSApplication. Tu pourras ensuite faire toutes les initialisations a partir de cette classe - initialisation des singleton compris.Ensuite, l'organisation des données se fera selon un arbre dont la racine est cette sous-classe de NSApplication. Le fait de ne pas utiliser IB t'impose cette structure avec un unique arbre.
Malheureusement, si tu ne veux pas entendre parler du MVC pour écrire des programmes un minimum complexe, même sans interfaces graphiques, que ce soit avec Cocoa ou non, je pense que va très vite nager dans le code.
Quelques idées pour commencer:
- Eh ouais, le MVC c'est vraiment un très bon début.
- Affichez les diagrammes de classes d'UML sous XCode (menu Design > Class Model > Quick Model). L'outil est très limité mais permet d'avoir une vue d'ensemble de son projet et de voir quelles classes ont trop de responsabilités, pour les simplifier.
Je reprends ici la démarche qu'on ma donné en cours pour modéliser. Je tiens à préciser qu'il ne faut pas suivre cela aveuglément à l'époque de la programmation Agile.
Tout cela se fait sur papier:
1) Lister les opérations, c'est à dire toutes les tâches que le programme doit effectuer.
2) Décomposer en sous-tâches, et encore en sous-tâches: on s'arrête lorsqu'on pense que notre design est suffisamment détaillé pour coder.
3) et seulement après, déterminer quelles sont les données nécessaires à l'accomplissement de ces tâches.
Normalement, avec cette méthode, vous devez être capable de modéliser chaque classe: un ensemble d'opérations proches, qui utilisent les mêmes données (variables d'instance).
Pour moi un programme objet est comme une entreprise où chaque ressource doit être
• autonome
• en communication avec quelques autres ressources (en nombre restreint, c'est mieux)
• en mesure d'échanger des messages
Par exemple, le modèle MVC c'est
• Un Hangar qui gère les tâches internes de stockage mais aucun choix stratégique (M)
• Un Chef de Hangar qui gère le gros du stockage, et qui répond à la clientèle (au sens large) (C)
• Un Client (V) qui coordonne ou réalise des demandes extérieures.
Quand je crée un projet, je prévois un système de communications robustes entre des ressources, en définissant des savoir-faire pour chaque ressource, presqu'indépendamment de l'objectif lui-même du projet, en cherchant la possibilité de réutiliser ces classes dans un contexte différent.
ça, c'est un détail pratique
La ressource initialisante du programme n'est pas une ressource de fonctionnement. Pour moi, elle peut disparaà®tre une fois le travail fait.
Monstres de code ? Là je ne vois pas, sauf pour l'initialisation sans IB où effectivement ça doit s'allonger considérablement. Par exemple, le fichier XML d'un MainMenu.xib contenant un controller et trois custom views représente 132 KO !!
Qui ça ?
Merise, ça date du cobol non ? ce n'est pas grave en soi, mais il y a depuis le modèle entité-association, qui d'ailleurs n'a jamais été compris par les informaticiens...
Ouais, et les boucles du Fortran...
Merise, même si elle est vieille et limitée, a deux gros avantages: elle reste accessible, et elle offre une démarche. Je crois que c'est ce qui est important ici. Tu ouvres n'importe quel bouquin sur UML, tu vas y voir les (12, non 16, non 22, je sais plus) types de diagrammes qu'elle propose, mais rien pour te dire comment on organise les classes.
J'ai beaucoup appris en suivant le cours du CNAM à ce sujet, même si je n'étais pas d'accord avec le prof (un retraité): lui disait qu'on commençait toujours par avoir un cahier des charges complet, moi j'ai jamais vu ça dans mon boulot en huit ans. C'était même pas la peine de lui parler programmation agile, mais là dedans, il y avait des idées à garder.
Non pour moi ça c'est l'esprit du C, on définit un catalogue de fonctions, et un catalogue de données informatiques appropriées (structure, arbres, listes, ....) compte-tenu des fonctions que l'on veut réaliser.
Pour moi, la programmation objet c'est définir un type d'objets (que j'ai appelés ci-dessus des ressources) qui seront susceptibles de répondre à un certain type de demandes.
Il faut donc cerner des types de messages et de communication, et là c'est un peu ton paragraphe 1, créer des classes correspondantes, en prévoyant que ces dernières devront pouvoir éventuellement être enrichies (et là cela rejoint la programmation Agile) sans que cela affecte l'architecture générale.
Quand à suivre des modèles tout faits, ce n'est pas ma nature, mais peut-être cela vient-il aussi du fait que je travaille en solo.