Meilleure stratégie (ou macros pour simplifier?) pour une structure en arbre

Réponses

• schlum Membre

  mars 2009 16:18 modifié #2

  dans 1238066617:

  
  Solutions possibles :

  • un bête NSDictionary : c'est KVC, facilement sérialisable... mais on peut enregistrer un peu n'importe quoi dedans donc côté error-checking des clés c'est pas terrible. Et côté facilement parcourable c'est pas ça : on peut bien faire un [tt][dict valueForKeyPath:@machin.truc.bidule][/tt] mais je préférerais qd mm une notation directe dict.machin.truc.bidule
    
  • Une classe perso dérivant de NSObject avec les variables d'instance qui vont bien
    

  
  

  
  
  Un mix des deux  :P
  Une classe dérivée de NSMutableDictionary qui teste les clés en entrée, avec éventuellement des ajouts de properties pour les clés courantes.
• Chacha Membre

  mars 2009 mars 2009 modifié #3

  dans 1238066617:

  
  Voilà , si vous avez des idées... elles sont toutes bienvenues
  

  
  
  Bah à  part les subtilités sur les macros, je vois pas trop. Tu connais le # et le ## ?
  #TOTO génère la chaà®ne "TOTO" au préprocessing
  et ## permet de concétaner.
  et les macros supportent le __VA_ARGS__ http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
  
  Rien de bien neuf, mais si on connaà®t pas...
  
  PS : C'est pour iPhone, donc pas de CoreData (même si je sais pas si ça aurait été adapté, mais au moins ça coupe court à  la possibilité ^^)
  Ah me semble bien que le SDK 3.0 contient du CoreData :-D
  
  +
  Chacha
• Céroce Membre, Modérateur

  mars 2009 16:18 modifié #4

  dans 1238066617:

  
  PS : C'est pour iPhone, donc pas de CoreData
  

  
  
  Et NSXMLDocument ?
  ça semble répondre à  ton cahier des charges.
• No Membre

  mars 2009 16:18 modifié #5

  dans 1238069831:

  
  

  dans 1238066617:

  
  PS : C'est pour iPhone, donc pas de CoreData
  

  
  
  Et NSXMLDocument ?
  ça semble répondre à  ton cahier des charges.
  

  
  
  PS : C'est pour iPhone, donc pas de NSXMLDocument.
• AliGator Membre, Modérateur

  mars 2009 mars 2009 modifié #6

  Grand merci pour vos réponses, je pensais pas déchaà®ner les foules pourtant avec ma question
  
  

  dans 1238068979:

  
  Un mix des deux  :P
  Une classe dérivée de NSMutableDictionary qui teste les clés en entrée, avec éventuellement des ajouts de properties pour les clés courantes.
  

  C'est pas idiot... j'y ai pensé à  un moment, mais me suis dit que quand je déclarais mes properties, il faudrait que j'écrive moi-même les setters/getters desdites propriétés pour faire un setValue:forKey et un valueForKey à  la place... donc j'avais oublié cette possibilité. Mais vu comme finalement les autres possibilités impliquent aussi de pisser pas mal de code... finalement ça pouraà®t être un bon compromis.
  
  Un truc comme ça donc :
  

  #define PROP_DECL(Type, var) @property(nonatomic, retain, setter=set_##var) Type var;<br /><br />#define PROP_DEF(Type, var) &#092;<br />-(Type)var { return (Type)[self valueForKey:@ #var]; } &#092;<br />-(void)set_##var:(Type)val { [self setValue:val forKey:@ #var]; }<br /><br />@interface Auteur : NSMutableDictionary {}<br />  PROP_DECL( NSString* , nom)<br />  PROP_DECL( NSString* , prenom)<br />  PROP_DECL( NSDate* , dateNaissance)<br />@end<br /><br />@implementation Auteur<br />  PROP_DEF(NSString* , nom )<br />  PROP_DEF(NSString* , prenom )<br />  PROP_DEF(NSDate* , dateNaissance )<br />@end<br /><br />/////////////////////////////////<br />... et les autres (Description, Societe) pareil<br />/////////////////////////////////<br /><br />@interface Logiciel : NSMutableDictionary {}<br />  PROP_DECL( Auteur* , auteur )<br />  PROP_DECL( Description* , description )<br />  PROP_DECL( Societe* , societe )<br />  PROP_DECL( NSString* , plateforme )<br />@end<br /><br />@implementation Logiciel<br />  PROP_DEF( Auteur* , auteur )<br />  PROP_DEF( Description* , description )<br />  PROP_DEF( Societe* , societe )<br />  PROP_DEF( NSString* , plateforme )<br /><br />-(void)init {<br />  if ((self = [super init])) {<br />    self.auteur = [[[[Auteur alloc] init] autorelease];<br />    self.description = [[[Description alloc] init] autorelease];<br />    self.societe = [[[Societe alloc] init] autorelease];<br />  }<br />}<br />@end
  

  J'ai rajouté le init pour pré-créer ma structure de dictionnaires quand même, pour que si je fais [soft setValue:@moi forKeyPath:@auteur.nom] il fonctionne bien (car si auteur est nil au lieu d'être un Auteur* existant, setValue:forKeyPath: marchera pas)... donc si je me suis pas gourré dans mon init, il va me créer un Auteur* (soit un NSMutableDictionary) qu'il va affecter à  la clé "auteur" du dictionaire principal "Logiciel", pareil pour description et societe, ce qui me permettra d'utiliser setValue:forKeyPath: sans soucis...
  Et du coup pas besoin d'implémenter NSCopying, c'est déjà  tout prêt, ni besoin de déclarer des variables d'instance qui font redondant avec les @property puisqu'on utilise un NSDictionary pour les stocker.
  
  
  Vous en pensez quoi, de cette solution ? (pas encore testée sur un vrai projet) ?
  
  Sinon au lieu de faire par héritage, je pensais aussi faire par wrapping : Auteur dériverait de NSObject, mais contiendrait une vi unique NSMutableDictionary* data. Et après on reprend le même principe. Avantage, pas de risque d'appeler les méthodes de NSMutableDictionary sur mon Auteur. Inconvénient, faut implémenter NSCopying, mais au moins il est générique, il suffit d'encoder data pour que ça sérialise tout l'objet, donc c'est "macrotisable".
  Je sais pas lequel est le plus propre...
  
  
  En effet sinon le XML c'est pas top car sur iPhone, pas de parsing DOM du XML, que du parsing SAX, donc ça va pas le faire.
• schlum Membre

  mars 2009 16:18 modifié #7

  Oui, en wrapping c'est limite plus propre effectivement 
• AliGator Membre, Modérateur

  mars 2009 mars 2009 modifié #8

  Hello les gens !
  
  Alors pour info, voilà  comment j'ai fini par implémenté la chose, en suivant vos conseils :
  
  Voilà  le début de mon .h (macros et classe de base) :

  <br />#define PROP_OBJ(Type, var) &#092;<br />@property(nonatomic, retain, setter=set_##var:) Type var;<br /><br />#define PROP_BOOL(var) &#092;<br />@property(nonatomic, assign, setter=set_##var:) BOOL var;<br /><br /><br /><br />@interface StructuralObject : NSObject &lt;NSCoding&gt;<br />{<br />	NSMutableDictionary* data;<br />}<br />@end
  

  
  
  Et le début de mon .m (macros et classe de base) :

  #undef PROP_OBJ<br />#define PROP_OBJ(Type, var) &#092;<br />-(Type)var { return (Type)[ data valueForKey:@#var ]; } &#092;<br />-(void)set_##var:(Type)val { [ data setValue:val forKey:@#var ]; }<br /><br />#undef PROP_BOOL<br />#define PROP_BOOL(var) &#092;<br />-(BOOL)var { return [(NSNumber*)[ data valueForKey:@#var ] boolValue]; } &#092;<br />-(void)set_##var:(BOOL)val { [ data setValue:[NSNumber numberWithBool:val] forKey:@#var ]; }<br /><br />@implementation StructuralObject<br />- (id) init<br />{<br />	self = [super init];<br />	if (self != nil) {<br />		data = [[NSMutableDictionary alloc] init];<br />	}<br />	return self;<br />}<br />- (id)initWithCoder:(NSCoder *)decoder<br />{<br />	//self = [super initWithCoder:decoder];<br />	data = [[decoder decodeObject] retain];<br />	return self;<br />}<br />- (void)encodeWithCoder:(NSCoder *)coder<br />{<br />	//[super encodeWithCoder:coder];<br />	[coder encodeObject:data];<br />}<br />- (void)setValue:(id)value forUndefinedKey:(NSString *)key<br />{<br />	// I have to implement this because we used a special set_xxx setter for xxx keys (because with #define macros we can&#39;t capitalize first letter to create setXxx, do we ?)<br />	NSString* setter = [NSString stringWithFormat:@&quot;set_%@:&quot;,key]; // the &quot;setter&quot; selector name we expect<br />	if ([self respondsToSelector:NSSelectorFromString(setter)]) // the corresponding setter for key xxx exists, so it&#39;s ok<br />		[data setValue:value forKey:key]; // set the value (same code as if we called set_xxx here)<br />	else<br />		[super setValue:value forUndefinedKey:key]; // the setter really does not exist, don&#39;t allow to set the value<br />}<br />- (void) dealloc<br />{<br />	[data release];<br />	[super dealloc];<br />}<br />-(NSString*)description<br />{<br />	return [data description];<br />}<br />@end
  

  Ces deux outils (les macros et la classe StructuredObject) me permettent de déclarer ensuite mes classes ainsi (dans le même .h et .m en l'occurrence) :

  // à  la suite dans mon .h :<br />@interface Person : StructuralObject  {}<br />	PROP_OBJ( NSString* , name )<br />	PROP_OBJ( NSString* , surname )<br />	PROP_OBJ( NSString* , address )<br />	PROP_OBJ( NSString* , zipCode )<br />	PROP_OBJ( NSString* , country )<br />	PROP_OBJ( NSString* , phoneOrMail )<br />@end<br />// ... et plein d&#39;autres classes du genre<br /><br />// à  la suite dans mon .m :<br />@implementation Person<br />	PROP_OBJ( NSString* , name )<br />	PROP_OBJ( NSString* , surname )<br />	PROP_OBJ( NSString* , address )<br />	PROP_OBJ( NSString* , zipCode )<br />	PROP_OBJ( NSString* , country )<br />	PROP_OBJ( NSString* , phoneOrMail )<br />@end<br />// ... et plein d&#39;autres classes du genre
  

  Avantage, c'est propre, une fois mes macros et ma classe de base StructuralObject prête, toutes mes classes ressemblent à  la classe Person citée ici en exemple... et que comme vous pouvez le constater, c'est exactement le même contenu mis dans le @interface et le @implementation, permettant de faire direct un copier/coller C'est la définition différente des macros dans le .h et le .m qui fait tout le travail.
  
  ---
  
  Et en plus ça permet tout de même des cas particuliers : par exemple j'ai une classe EntityGroup (que j'ai simplifiée ici) qui gère entre autres un CGPoint... variable qui ne peut pas être mise dans le dictionnaire. Du coup soit je l'encodais en NSDictionary ou NSValue pour le stocker... soit je mettais une variable d'instance pour ce cas particulier, ce que j'ai fini par faire, De plus cette classe est un bon exemple aussi car elle contient des v.i. elles-mêmes de type StructuralObject (enfin des sous-classes), qu'il faut donc penser à  initialiser :

  @interface EntityGroup : StructuralObject<br />{<br />	CGPoint position;<br />}<br />	PROP_OBJ( Person* , driver )<br />	PROP_OBJ( Vehicle* , vehicle )<br />	@property(nonatomic, assign) CGPoint position; // lui est associé à  la v.i. et non stocké dans le dico<br />@end<br />
  

  Et donc pour l'implémentation :

  @implementation EntityGroup<br />@synthesize position;<br /><br />- (id) init<br />{<br />	self = [super init];<br />	if (self != nil) {<br />		self.driver = [[[Person alloc] init] autorelease];<br />		self.vehicle = [[[Vehicle alloc] init] autorelease];<br />	}<br />	return self;<br />}<br />- (void)encodeWithCoder:(NSCoder *)coder {<br />	[super encodeWithCoder:coder];<br />	[coder encodeObject:[NSValue valueWithCGPoint:position]]; // du coup faut penser à  l&#39;encoder lors de la sérialisation aussi<br />}<br />- (id) initWithCoder:(NSCoder*)decoder {<br />	self = [super initWithCoder:decoder];<br />	position = [(NSValue*)[decoder decodeObject] CGPointValue]; // et à  le décoder lors de la désérialisation puisqu&#39;il n&#39;est pas dans le dico &quot;data&quot;, lui.<br />	return self;<br />}<br /><br />PROP_OBJ( Person* , driver )<br />PROP_OBJ( Vehicle* , vehicle )<br />@end
  

  Voilà , ça m'a l'air pas mal comme solution !
  
  Gros avantage : c'est très facile à  implémenter, et vu le nombre de classes du genre que j'ai dans ma structure hiérarchique, c'est un point important.
  Quand je veux déclarer un nouveau "groupe de propriétés" à  utiliser dans ma structure, j'écris [tt]@interface MonType : StructuredObject {}[/tt] puis je liste toutes les propriétés que je veux avec [tt]PROP_OBJ(type,var)[/tt], et je termine avec [tt]@end[/tt]... Et ensuite j'ai simplement à  copier/coller exactement les mêmes lignes dans le @implémentation Comme on le voit pour le cas de la classe "Person" 
  
  
  Voilà , ça devient du coup bien plus sympathique que ce vers quoi j'étais parti initialement, donc merci de vos suggestions
  
  (PS : Je n'ai pas encore testé le NSCoding même si je l'ai implémenté dans ma classe StructuredObject, faut que je vérifie que ça marche bien)
• 6ix Membre

  juillet 2009 16:18 modifié #9

  Je tombe sur ce sujet qui me paraà®t très intéressant, même quelques mois après la disucssion 
  
  Avec le recul, que penses-tu de ta manière de faire ? Est-ce qu'elle correspond bien à  ce que tu voulais, est-ce réellement plus pratique ?
  
  En tout cas je garde l'idée dans un coin, cela peut être très utile si on a beaucoup de classes du genre à  créer.