Encore mon problème d'array qui se dupliquent

Réponses

• Bru Membre

  décembre 2004 22:45 modifié #2

  Le peu de code que tu as mis me hérisse le poil...
  
  En fait, détaillons les données et leurs relations :
  - tu as 1 carnet de plongée.
  - 1 carnet de plongée contient X plongées.
  - 1 plongée contient 1 profil de plongée.
  
  En conclusion, 1 carnet de plongée stocke (indirectement) X profils de plongée.
  
  Or tu déclares (variable d'instance) et tu alloues (méthode init) le NSArray du profil des plongée comme pour le carnet de plongée : donc tu as 1 carnet de plongée avec 1 profil de plongée.
  
  C'est pas étonnant que toutes les plongées de ton carnet partage le même profil (techniquement, tu utilises le même objet pour chaque plongée).
  
  J'aimerai connaà®tre le code que tu utilises lorsque tu déclares/créés une nouvelle plongée que tu ajoutes dans le cranet...
  
  .
• Veillard Membre

  décembre 2004 22:45 modifié #3

  Le peu de code que tu as mis me hérisse le poil...

  
  Ca ne m'étonne pas 
  
  

  
  En fait, détaillons les données et leurs relations :
  - tu as 1 carnet de plongée.
  - 1 carnet de plongée contient X plongées.
  - 1 plongée contient 1 profil de plongée.
  

  
  Tout à  fait ça
  
  

  J'aimerai connaà®tre le code que tu utilises lorsque tu déclares/créés une nouvelle plongée que tu ajoutes dans le cranet...

  
  Je t'envoie ça, ne rigole pas, promis 
• Bru Membre

  décembre 2004 22:45 modifié #4

  Bon, j'ai un peu regardé...
  
  Sincèrement, je pense que tu as fauté dans le sens où tu as mélangé données fondamentales et UI (via les classes contrôleurs)...
  
  Pour moi, tu devrais avoir une classe PLONGEE et une classe CARNET indépendantes toutes 2 (dérivant de NSObject). En faisant ça, tu vois tout de suite ce qui appartient à  CARNET, ce qui appartient à  PLONGEE...
  
  Par exemple (selon ton code) :
  

  <br />@interface Carnet : NSObject<br />{<br />&nbsp; &nbsp; NSMutableArray&nbsp; *tableauDesPlongees;<br />}<br />
  

  
  
  et
  

  <br />@interface Plongee : NSObject<br />{<br />&nbsp; &nbsp; int nbPlongee;<br />&nbsp; &nbsp; NSDate *date;<br />&nbsp; &nbsp; float coeff;<br />&nbsp; &nbsp; NSString *pmBm;<br />&nbsp; &nbsp; NSString *lieu;<br />&nbsp; &nbsp; NSString *site;<br />&nbsp; &nbsp; NSString *palanquee;<br />&nbsp; &nbsp; NSString *epaves;<br />&nbsp; &nbsp; NSString *bateau;<br />&nbsp; &nbsp; NSMutableArray&nbsp; *profilProfondeur;<br />}<br />
  

  
  
  .
• Veillard Membre

  décembre 2004 22:45 modifié #5

  OK je vais essayer de refondre tout ça  :boss):
  Merci
• Veillard Membre

  décembre 2004 22:45 modifié #6

  C'est l'horreur, j'ai plantages sur plantages, je ne sais pas par quel bout commencer 
• muqaddar Administrateur

  décembre 2004 22:45 modifié #7

  Courage favouille...
  C'ets toujours comme ça quand on revoit la structure de son appli...
  ça m'est arrivé, j'hésitais pas à  commenter de gros morceaux de code pour voir ce qui allait pas...
• Bru Membre

  décembre 2004 22:45 modifié #8

  Tout d'abord, il ne faut pas toucher à  la structure actuelle de l'appli (on verra ça plus tard).
  
  Pour le moment, tu construits tes classes, et surtout tu codes les méthodes que tu auras besoin...
  
  Une fois tout ça terminé, là  tu commenceras à  remplacer tes arrays et tes dictionarys par des appels à  tes nouvelles classes.
  
  .
• Veillard Membre

  décembre 2004 22:45 modifié #9

  OK, j'avais commençé par la fin.
  Quand tu parles de "coder les méthodes", tu veux parler des différentes variables accesseurs qui seront appelées ultérieurement ?
• Bru Membre

  décembre 2004 22:45 modifié #10

  Entre autre oui...
  
  Par exemple, pour la classe CARNET, je vois quelques chose comme ça :
  
  - (void)addPlongee:(PLONGEE *)plongee;
  - (PLONGEE *)plongeeAtNumber:(int)number;
  - (void)removePlongeeAtNumber:(int)number;
  - (void)insertPlongee:(PLONGEE *)plongee atNumber:(int)number;
  etc...
  
  Et pour PLONGEE :
  - (void)setDate:(NSDate *)date;
  - (void)setLieu:(NSString *)lieu;
  - (void)setCoeff:(float)coeff;
  - (NSDate *)date;
  - (NSString *)lieu;
  - (float)coeff;
  - (NSArray *)profil;
  etc...
  
  .
• Veillard Membre

  décembre 2004 22:45 modifié #11

  Merci Bru.
  
  J'ai déjà  fait l'inventaire de mes variables d'instance.
  Je continue... 
• Bru Membre

  décembre 2004 22:45 modifié #12

  N'oublie pas non plus les méthodes de codage/archivage (et leurs inverses) pour stocker ensuite ton carnet (avec ses plongées et ses profils) sur disque.
  
  .
• Veillard Membre

  décembre 2004 22:45 modifié #13

  OK, je vérifie tout ça...
• Veillard Membre

  décembre 2004 22:45 modifié #14

  Bon, ça y est, j'ai codé les méthodes pour plus de 60 variables. 
  
  Par contre j'ai du mal à  saisir quand tu écris :
  

  - (void)addPlongee:(PLONGEE *)plongee;
  

  
  
  J'avais utilisé un NSDictionary
  

  - (NSDictionary *)createDive;
  

  
  avec toutes les clés à  l'intérieur.
  
  Ce qui m'inquiète le plus, c'est le stockage sur disque. J'espère que je peux réutiliser mes anciens fichiers ? (XML)
  
  Autre chose, par exemple pour :
  
  

  - (void)setDate:(NSDate *)myDate;<br />- (NSDate *)date;
  

  
  
    j'ai écrit dans "Plongee.h"
  
  

  - (void)setDate:(NSDate *)myDate<br />{<br />	id oldData = date;<br />	date = [myDate retain];<br />	[oldData release];<br />}<br /><br />- (NSDate *)date<br />{<br />	return date;<br />}<br />
  

  
  
  Par contre, est-ce utile de mettre
  
  

  - (void)setCoeff:(int)myCoeff;<br />- (int)coeff;<br />
  

  
  
  Est-ce que :
  
  

  - (int)coeff<br />{<br />	return coeff;<br />}<br />
  

  
  
  ne suffit pas (c'est un int et non un NSNumber par ex.)  ???
• Bru Membre

  janvier 2005 22:45 modifié #15

  dans 1104486642:

  Par contre j'ai du mal à  saisir quand tu écris :
  

  - (void)addPlongee:(PLONGEE *)plongee;
  

  
  J'avais utilisé un NSDictionary
  

  - (NSDictionary *)createDive;
  

  
  avec toutes les clés à  l'intérieur.
  

  
  
  Tu fais comme tu veux. Là  ce n'est pas important.
  Même si la formulation addPlongee est plus proche de l'esprit cocoa. Par exemple,voici ce que cela donnerai :
  

  <br />{<br />    PLONGEE *plongee;<br /><br />    plongee=[[PLONGEE alloc] init];<br />    [plongee setProfonfeur:18.3];<br />    [plongee setPalanquee:[NSArray arrayWithObjects:@&quot;Bruno&quot;, @&quot;Catherine&quot;, nil]];<br />    [plongee setDuree:43];<br />    [plongee setCommentaire:@&quot;congre, vieille, girelle paon, mur de corynactis&quot;];<br />    [moncarnet addPlongee:plongee];<br />    [plongee release];<br />}
  

  
  
  .
• Bru Membre

  janvier 2005 22:45 modifié #16

  dans 1104486642:

  
  Ce qui m'inquiète le plus, c'est le stockage sur disque. J'espère que je peux réutiliser mes anciens fichiers ? (XML)
  

  
  
  Quoiqu'il en soit, ça sera toujours récupérable (en effet, il faudra prévoir ton ton logiciel une section d'import export, afin notamment de récupérer des données provenant d'autres softs de plongée).
  
  Maintenant, se pose la question du volume des données, pour lequel le format XML ne s'adapte plus trop...
  
  .
• Bru Membre

  janvier 2005 janvier 2005 modifié #17

  dans 1104486642:

  
  Autre chose, par exemple pour :
  

  - (void)setDate:(NSDate *)myDate;<br />- (NSDate *)date;
  

  
  j'ai écrit dans "Plongee.h"
  

  - (void)setDate:(NSDate *)myDate<br />{<br />	id oldData = date;<br />	date = [myDate retain];<br />	[oldData release];<br />}<br />- (NSDate *)date<br />{<br />	return date;<br />}<br />
  

  
  

  
  
  Je préfère (mais ce n'est qu'affaire de goût), une structure comme celle-là  (je nommerai _date la variable d'instance contenant la date dans l'objet):
  

  <br />- (void)setDate:(NSDate *)myDate<br />{<br />    [_date release];<br />    _date=[[NSDate alloc] initWithTimeIntervalSinceNow:[myDate timeIntervalSinceNow]];<br />}<br /><br />- (NSDate *)date<br />{<br />    return [NSDate dateWithTimeIntervalSinceNow:[_myDate timeIntervalSinceNow]];<br />}<br />
  

  
  
  Ici, on mémorise toujours une copie de la date passée en paramètre. De même, on retourne une copie de la date mémorisé dans l'instance de classe.
  
  .
• Bru Membre

  janvier 2005 22:45 modifié #18

  dans 1104486642:

  
  Par contre, est-ce utile de mettre
  

  - (void)setCoeff:(int)myCoeff;<br />- (int)coeff;<br />
  

  
  Est-ce que :
  

  - (int)coeff<br />{<br />	return coeff;<br />}<br />
  

  
  ne suffit pas (c'est un int et non un NSNumber par ex.) ???
  

  
  
  Je ne comprends pas trop le problème...
  
  .
• Veillard Membre

  janvier 2005 22:45 modifié #19

  Bonjour Bru et bonne année 
  
  Oui, ça concerne :
  

  - (void)setCoeff:(int)myCoeff;
  

  
  Je ne sais pas quoi mettre dedans. ???
  Dans le livre "Cocoa par la pratique", il n'y a pas ce type de méthode pour les int et les float...
• Eddy58 Membre

  janvier 2005 22:45 modifié #20

  Et bien comme ce n'est pas un objet, tu changes tout simplement l'ancienne valeur de coeff par la nouvelle :
  
  

  <br />- (void)setCoeff:(int)myCoeff<br />{<br />coeff=myCoeff;<br />}<br />
  
• cbrandt Membre

  janvier 2005 22:45 modifié #21

  dans 1104688697:

  
  Je préfère (mais ce n'est qu'affaire de goût), une structure comme celle-là  (je nommerai _date la variable d'instance contenant la date dans l'objet):
  

  <br />- (void)setDate:(NSDate *)myDate<br />{<br />    [_date release];<br />    _date=[[NSDate alloc] initWithTimeIntervalSinceNow:[myDate timeIntervalSinceNow]];<br />}<br /><br />- (NSDate *)date<br />{<br />    return [NSDate dateWithTimeIntervalSinceNow:[_myDate timeIntervalSinceNow]];<br />}<br />
  

  
  
  Ici, on mémorise toujours une copie de la date passée en paramètre. De même, on retourne une copie de la date mémorisé dans l'instance de classe.
  
  .
  

  
  
  c'est pas plus simple comme ça ? ???
  
  

  <br />- (void)setDate:(NSDate *)myDate<br />{<br />    [_date release];<br />    _date=[myDate copy];<br />}<br /><br />- (NSDate *)date<br />{<br />    return [_date copy];<br />}<br />
  
• Veillard Membre

  janvier 2005 22:45 modifié #22

  Et bien comme ce n'est pas un objet, tu changes tout simplement l'ancienne valeur de coeff par la nouvelle 

  
  Désolé, j'ai parlé trop vite. J'ai vu mon erreur p. 98 sur le livre. 
• Bru Membre

  janvier 2005 22:45 modifié #23

  dans 1104693911:

  
  c'est pas plus simple comme ça ? ???
  

  
  
  Toutes les classes ne se conforment pas complètement au protocole copying. Alors je fais mes propres copies, ça coûte pas trop de code en plus et ça me rassure...
  
  .
• Veillard Membre

  janvier 2005 22:45 modifié #24

  Donc, on peut faire quelque chose du style :
  
  

  - (void)setLieu:(NSString *)myLieu<br />{<br />&nbsp; &nbsp; [_lieu release];<br />&nbsp; &nbsp; _lieu=[[NSString alloc] initWithString:@&quot;&quot;];<br />}<br /><br />- (NSString *)lieu<br />{<br />&nbsp; &nbsp; return [NSString stringWithString:@&quot;&quot;];<br />}
  

  
  
  Pour les NSString ?
• Bru Membre

  janvier 2005 22:45 modifié #25

  dans 1104697326:

  
  Donc, on peut faire quelque chose du style :
  

  - (void)setLieu:(NSString *)myLieu<br />{<br />    [_lieu release];<br />    _lieu=[[NSString alloc] initWithString:@&quot;&quot;];<br />}<br />- (NSString *)lieu<br />{<br />    return [NSString stringWithString:@&quot;&quot;];<br />}
  

  
  Pour les NSString ?
  

  
  
  Oui, c'est comme ça que je fais (sauf que dans ton code, il faut remplacer les @";" par _lieu ou myLieu) :
  [tt]- (void)setLieu:(NSString *)myLieu
  {
  [_lieu release];
  _lieu=[[NSString alloc] initWithString:myLieu];
  }
  - (NSString *)lieu
  {
  return [NSString stringWithString:_lieu];
  }[/tt]
  
  .
• Baarde Membre

  janvier 2005 22:45 modifié #26

  dans 1104688697:

  Je préfère (mais ce n'est qu'affaire de goût), une structure comme celle-là  (je nommerai _date la variable d'instance contenant la date dans l'objet):
  

  <br />- (void)setDate:(NSDate *)myDate<br />{<br />    [_date release];<br />    _date=[[NSDate alloc] initWithTimeIntervalSinceNow:[myDate timeIntervalSinceNow]];<br />}<br /><br />- (NSDate *)date<br />{<br />    return [NSDate dateWithTimeIntervalSinceNow:[_myDate timeIntervalSinceNow]];<br />}<br />
  

  
  
  Ici, on mémorise toujours une copie de la date passée en paramètre. De même, on retourne une copie de la date mémorisé dans l'instance de classe.
  
  .
  

  
  Avec quelques dates et chaà®nes ça va mais si tout le monde fait comme ça, je comprends où file ma mémoire... 
• Bru Membre

  janvier 2005 janvier 2005 modifié #27

  dans 1104706292:

  
  Avec quelques dates et chaà®nes ça va mais si tout le monde fait comme ça, je comprends où file ma mémoire...
  

  
  
  Ouais, surtout quand on sait pas utiliser release ou autorelease correctement !
  
  Bref, même Apple s'y met : voir le bug de 10.0 ou setTitle de NSWindow ne faisait qu'un retain sur la NSString passée en paramètre. Or si cette NSString était une NSMutableString, et si par la suite dans programme, on modifiait cette chaà®ne, ça foutait bien-sûr la grouille dans la barre de titre de la fenêtre... Maintenant, c'est bien une copie de la chaà®ne qui est utilisée pour le titre.
  
  .
• ClicCool Membre

  janvier 2005 22:45 modifié #28

  Salut,
  
  Je suis d'accord ++ avec Bru pour l'usage de copies dans les accesseurs.
  Celà  impose un code plus propre et interdit complètement la modification d'une variable d'instance sans passer par l'accesseur approprié.
  Ce qui me semble plus conforme à  l'encapsulation objet.
  
  Pour ce qui est de l'usage des retain, release et autorelease c'est un effort à  faire et une bonne gymnastique garantissant la bonne conception du code. (même si c'est pas toujours facile de repérer une fuite mémoire dans un code un peu fourni )
• ClicCool Membre

  janvier 2005 22:45 modifié #29

  Deux petites précisions néanmoins,
  
  1°) De mon coté j'ai une préférence pour les copies de variables d'instances renvoyées par mes accesseurs "getters".
  Je les renvoies toujours autoreleasées.
  
  D'abbord parcequ'il n'est pas question qu'un accesseur renvoie des copies simples et un autre des copies releasées, sinon on s'y perd  ???
  
  Ensuite parceque certains appels aux accesseurs ne sont pas directement faits par mon code.
  Par exemple pour une tableView gérée par binding et pour laquelle le nombre d'appel peut être important (beaucoup de copies faites) sans que j'ai de façon simple l'opportunité d'effectuer les releases à  postériori.
  Les onjets générant ces appels comme les arrayControllers sachant parfaitement adresser un retain (puis un release) à  la copie qu'ils reçoivent, je trouve plus propre de leur renvoyer une copie autoreleasée qui sera désalouée dès que le contrôleur n'en a plus besoin.
  
  Le problème est sensiblement le même avec le dataSource d'une TableView du reste.
  Il y est plus simple (dans les méthode de datasource) de renvoyer directement la copie autoreleasée du getter que d'appeler le getter puis autoreleaser la copie récupérée avant de la renvoyer pour la tableView.
  
  2°) Bien sur il y a des Variables d'instance qui sont plus des pointeurs vers d'autres objets (conteneurs ou délégates etc...) que des valeurs. Le getter est alors souvent appelé pour récupérer un pointeur sur un objet auquel on va adresser des méthodes. Là , le plus souvent, pas question de renvoyer une copie
  
  
• Veillard Membre

  janvier 2005 22:45 modifié #30

  Bon, ça avance petit à  petit. 
  Juste une question : "moncarnet" dans
  

  [moncarnet addPlongee:plongee];
  

  
  est-il un NSMutableArray ?
  J'ai essayé et ça ne marche pas  ???
  
• Bru Membre

  janvier 2005 22:45 modifié #31

  dans 1104783816:

  
  Bon, ça avance petit à  petit.
  Juste une question : "moncarnet" dans
  

  [moncarnet addPlongee:plongee];
  

  
  est-il un NSMutableArray ?
  J'ai essayé et ça ne marche pas ???
  

  
  
  Non, c'est aussi une classe dérivant de NSObject, dont la principale variable est le NSMutableArray stockant les objets PLONGEE, mais contenant aussi d'autres données (à  l'image de la première page de ton carnet de plongée FFESSM -ancien format-).
  
  .