Salut,

[EDIT: Consignes obsolètes, voir plutôt mon second message /]

En ce moment j'essaie de développer un petit logiciel de gestion d'emploi du temps scolaire, et je bloque sur une chose dont on a pas de réponse à la seule lecture du tutoriel ici même. Pour simplifier, je vais ramenner ça à l'exemple du RPG de ce tuto :
- Donc, imaginons que le jeu nous fasse diriger David, objet de type Personnage et seul représentant actuel de sa classe. Puis, nous voulons aggrandir notre équipe enr ecrutant un nouveau Personnage dans le jeu, en choisissant ses caractéristiques.
- Ensuite, nous décidons de changer la taille (c'est un attribut) de tous les Personnage du jeu afin qu'ils aient la même.

1) Comment coder le programme de façon à pouvoir créer autant de clips (vielle habitude de Flash) d'objets que l'utilisateur le veut ? Faut-il faire un tableau de Personnage qui alloue de la mémoire a mesure que l'on créé des personnages ?

2) Comment changer l'attribut d'une classe de façon à ce que toutes ses occurences la possèdent immédiatement ? Faut-il modifier tous les objets manuellement un par un ou existe-il justement une "méthode" ?

Citation : SpotZup

1) Comment coder le programme de façon à pouvoir créer autant de clips que l'utilisateur le veut ? Faut-il faire un tableau de Personnage qui alloue de la mémoire a mesure que l'on créé des personnages ?

Comment coder, c'est toi qui cherchera... Sinon, les différentes instances de ta classe il faut que les stocke quelque part pour pouvoir les utilises facilement. Je te conseille de voir du côté de la STL avec les List ou les Array qui permettent de stocker des objets d'une même classe. Il te suffira alors d'ajouter de nouveaux objets au tableau selon tes besoins.

Citation : SpotZup

2) Comment changer l'attribut d'une classe de façon à ce que toutes ses occurences la possèdent immédiatement ? Faut-il modifier tous les objets manuellement un par un ou existe-il justement une "méthode" ?

Si l'attribut en question a une valeur commune à toutes les instances de la classe, c'est-à-dire si l'attribut ne dépend pas du personnage mais de la classe, alors il faut le déclarer comme static. Sinon, bah la méthode il faut que tu la crées toi-même... Elle devra circuler dans toutes les instances de ta classe et faire la modification appropriée.
Sinon tu peux toujours faire un mixte des deux techniques, c'est-à-dire que tu définis un attribut de classe et un attribut d'instance, et l'accesseur de l'attribut retourne l'addition de l'attribut de classe et celui de l'instance... Ainsi si tu veux modifier les valeurs de tous les attributs en même temps et avec un même écart, tu modifies l'attribut de classe, et sinon tu modifies l'attribut d'instance...

Ok merci, le static marche et pour la STD va falloir que je m'y mette ! Mais voila, mon problème est en fait encore différent et cette fois je vais le préciser plus spécifiquement :

Je réalise donc un emploi du temps.
J'ai une classe Matiere servant à créer de nouvelles matières.
L'utilisateur doit d'abord créer une nouvelle matière, par exemple Maths en renseignant quelques trucs (nom du prof, couleur de l'étiquette..), puis il créera plusieurs instances de cette classe Maths pour les différents cours qu'il a dans la semaine (chaque instance possèdera ses propres horraires).

Voila le concept, j'avoue que c'est un peu tordu peut-être.. Ma vraie question est de savoir en gros comment je dois réfléchir pour pouvoir créer dynamiquement des nouvelles classes héritées de la classe Matiere (donc Maths, Physique..). A la limite même pas besoin qu'elles héritent de Matiere, mais j'aimerais pouvoir créer autant de classe que l'utilisateur le désire. Je me débrouillerai ensuite pour en faire plusieurs instances.

L'intérêt de cela est que tous les objets de type Maths auront en commun la variable statique du nom du prof de maths par exemple. S'il existe un moyen plus simple aussi je suis preneur !

En Objective-C tu ne peux pas créer de classe dynamiquement, et là ça n'aurait aucun intérêt.
Ce qu'il faut que tu fasses ce sont deux classes séparées : la classe Matières dont on pourra créer une instance Math, et une classe Horaire, qui indiquera les heures de début et de fin du cours, le jour, et le lieu du cours.
Et dans ta classe Matières tu mets comme attribut d'instance, un tableau d'Horaire, comme ça le mec crée une matière et il remplis cette matière d'horaire.

Ah oui pas bête du tout et largement plus simple que ce sur quoi j'étais parti ! En fait j'avais déja pensé a un truc similaire mais j'avais abandonné parce que deux cours de Maths par exemple peuvent différer par leurs horraires mais aussi par la salle dans lequel le cours à lieu. Cependant, lire ton post m'a donné des idées. Je pense que je vais essayer par exemple de mettre les horraires et la salle dans la même sous classe.

Enfin bref, ça me va bien comme ça, c'est la réponse que j'attendais et j'avais peur que personne ne comprenne mon post. Merci

Quel intérêt d'une sous-classe ?

Faire une sous-classe ne lit aucunement les deux classes ! Ce que tu veux faire c'est lier une classe à une autre, et le seul moyen de le faire c'est de référencer l'instance d'un objet de la première classe dans la deuxième classe.
Ça fonctionne exactement comme le nom de la matière impliquée, est-ce que le type string est une sous-classe de la classe Matière ? Non et pourtant tu l'utilises dans ta classe, et le nom est lié à l'instance. Pas besoin de faire une classe matière et une sous-classe de Matière nommée Horaire ça ne les liera pas, tout ce que ça va faire c'est donner les méthodes et les attributs de Matières à la classe Horaire...
La relation qui lit une classe et sa sous-classe est la relation de type "est un"... Est-ce qu'une horaire EST UNE matière ? Non... Donc pas de sous-classe.

Euh oui je m'étais surement mal exprimé, je savais pas que sous classe avait une définition stricte.. Je disais juste ça parce que Horraire est utilisé par Matière, sans en être un héritier. Bon ça y est j'ai fini ma petite mixture. Au début j'étais parti pour faire en sorte que chaque Matiere possède ses Horraires. J'aurais peut-être du garder ce système d'ailleurs, mais ça faisait du code trop long à mon gout, du style

Maintenant j'ai séparé les deux classes, ce qui n'a pas vraiment d'intérêt vu que chaque matière ne possède qu'une Horraires:

En fait Horraire est composé d'une structure qui me permet d'en faire une liste chainée. Première fois que je les utilise, mon code est surement très mauvais c'est pour ça que je n'écris que cette partie

Edit: EN y réfléchissant c'est bête de les avoir séparés, si je supprime une Matiere j'aimerai autant que ça supprime ses horraires avec. Ralala je me suis pris la tête une bonne partie de l'aprem dans ce programme, j'abandonne pour ce soir !

Bah déjà, pour les horaires tu peux les détruire en même temps que la matière qui les possède grâce au destructeur de Matière. Ensuite, je t'avais suggéré de séparer Horaire et Matière car tu pouvais juste faire une liste de plusieurs horaires différents pour une même matière, du style :



Chaque tiret étant une instance d'Horaire différente, là faire deux classes séparées aurait été logique.

Ensuite, une "sous-classe" c'est une classe qui hérite d'une "super-classe". Une sous-classe est capable d'exécutée toutes les méthodes de sa super classe et possède aussi tous ses attributs, c'est ce qu'on appelle l'héritage.

Ah mais oui je suis bête ! En fait j'ai pas fais les choses comme tu me les avais conseillées: chaque objet de type Horraires est actuellement composé de l'ensemble des horraires d'une certaine matière. En fait ma classe Horraires se compose d'une liste chainée de toutes les heures de cours (avec leur salle et leur durée). C'est pour ça que je n'avais qu'un objet Horraires par Matiere..

Je suppose que j'ai mal raisoné "objet", j'ai juste vu les classes comme des structures.. Je pense que je vais tout changer, et faire comme tu dis: chaque Horraires représentera un cours, et une matière sera composée de plusieurs Horraires. En fait ça revient un peu au même finalement J'arrête pas de me contredire. Vaut-il mieux que je fasse un tableau d'Horraires ou une liste chaînée ? Sachant que je maitrise très mal les listes mais il me semble que ça peut devenir meilleur qu'un tableau dans un cas comme ça.

En tout cas tu m'as vraiment bien aidé et fais progresser, sans toi j'aurais sûrement abandonné mon idée, encore merci =)

Le problème de la liste chaînée c'est que, pour avoir le l'élément N, tu as besoin de passer par N objets, tu dois circuler dans tout le tableau à chaque fois, alors qu'avec un tableau tu accèdes directement à l'élément N.

Ouais je sais j'ai plus ou moins pigé la différence entre tableau et liste chaînée, et justement je trouve que les listes vont mieux dans mon cas parce que j'aurais jamais beaucoup d'éléments (on a pas 36 cours de maths par semaine), donc pas grave si je dois tous les traverser. Par contre il peut être fréquent que l'utilisateur supprime/ajoute des cours de maths, et j'ai pensé que c'étais plus simple à gérer avec des listes, au moins au niveau de la mémoire allouée.