Discussion :

[Klaim]

Ah ben non is_checked suppose que tu vas parcourir un certain nombre d'icones pour voir laquelle est checkée/selectionnée. Je parlais d'un cas ou tu ne peux en avoir qu'une seule a la fois ou pas du tout.

C'est correcte logiquement, mais pas du poitn de vu des perfs! (surtout
De plus, tu as toujours le risque d'arriver a un état ou plusieurs icones sont selectionnées en même temps, or si ce n'est pas le comportement voulu (une seule maximum) c'est potentiellement un probleme.

En fait mon exemple n'est pas clair.
Imaginons que je fasse un petit jeu où on a une représentation de la main droite du héros. Cette main ne peut tenir qu'un seul item a la fois pour l'utiliser, ou pas d'item du tout. Chaque item est différent et unique et possède un pouvoir activé dés que le joueur le met dans la main du heros (une methode appliquant le pouvoir, appelée régulièrement).
Tu as globalement deux manières de faire la partie qui permet de savoir quel objet on a dans la main (pour pouvoir appeler sa methode de pouvoir) ou qu'il n'y a pas d'objet dans la main :
a) utiliser un identifiant (par exemple un index) et déclarer une valeur de cet identifiant qui corresponds à "pas d'objet".
b) utiliser un pointeur vers l'objet en question, si il est a null alors il n'y a pas d'objet dans la main.

En fait, c'est la même solution, sauf que a) nécessite de coder quelque chose qui est déjà là au final dans le language. De plus a) t'oblige a connaitre dans le code appelant la façon dont sont organisés les objets item. Même si le code est minime, c'est le même principe.
Autant utiliser b) dans ce cas là par exemple.

[loufoque]

Pareil, utiliser un type qui rend explicitement optionnel le truc est bien plus sûr que des pointeurs.

[Emmanuel Deloget]

Je sais que c'est un peu hors sujet, mais je n'ai pas encore trouvé d'explication suffisament convaincante de cette affaire liée aux pointeurs NULL (comme quoi, avoir à en gérer serait un code smell...). Est-ce que quelqu'un maitrise bien le sujet ?

[yan]

Pareil, utiliser un type qui rend explicitement optionnel le truc est bien plus sûr que des pointeurs.

Si je comprend bien ce que tu dit, tu as toujours un objet qui correspond au NULL ‽
En gros un objet non initialisé que tu peut tester.
Alors quel différence avec le teste d'un pointeur à 0 ؟


ce fork à créé un thread :
http://www.developpez.net/forums/sho...13#post3523313
merci de continuer dans celui ci

[r0d]

Pour revenir au sujet initial, je pense qu'il faut faire attention à ce que l'on entend par "méthode" et de toujours spécifier le contexte et à quel niveau on se situe, sinon le mot "méthode" a encore moins de sens que la vierge. Je m'explique:

Par exemple, 2 cas (je prend des extrêmes pour que ce soit plus clair):
1/ Tu dois concevoir le produit de A à Z, gérer le client (s'assurer qu'il sait ce qu'il veut et qu'il accepte ce que tu lui proposes), les fournisseurs (s'il y en a), gérer une équipe (recrutement etc.).
2/ Ton chef te fourni les diagrammes UML complets des 3 classes que tu dois implémenter.

Ce sont des extrêmes, mais on voit bien ici que les méthodes que nous allons appliqués n'ont rien en commun.

Ensuite, des méthodes, il en existe beaucoup, et à tous les niveaux. Maintenant, après quelques expériences plus ou moins réussies, je préfère aujourd'hui utiliser ces méthodes comme des FAQ que comme un guide complet, je veux dire que je vais y pêcher des idées plutôt que de les suivre à la lettre. Car dans la vraie vie, aucune méthode n'est universelle. Par exemple tu ne vas par dérouler un RUP complet pour faire un batch de copie de BD. Tu ne va pas non plus te lancer dans du XP "à la lettre" si tu es le seul développeur.

Idem quand on parle de conception, ça dépend du projet. On ne fait pas systématiquement les 9 diagrammes UML (d'ailleurs ça n'aurait aucun sens).

Pour ma part, pour un projet de taille moyenne (du style: 1 CP, 6 developpeurs dont 1 senior), je trouve que le mix suivant fonctionne bien:
1 - analyse fonctionnelle
-> on ferme le cahier des charges ("fermer" c'est un bien grand mot, mais il est ultra important de limiter les modifications "en vol" du cahier des charges)
-> description des "use case". Les "use case" sont la colonne vertébrale du projet, je crois aujourd'hui qu'il est indispensable de bien les gérer des le début.
-> description des tests à partir des UC (use case). Je ne parle pas ici des tests unitaires (je ne suis pas trop pour les tests unitaires d'ailleurs), mais des tests d'utilisation. En gros, un test pour chaque UC.

2 - conception
-> ici c'est selon les besoins. Les difficilement évitables sont le diagramme de classe et au moins un diagramme de collaboration. Depuis que je ne suis plus en France, je n'ai bossé que sur des projets où un diagramme détat et un diagramme de séquence sont indispensables, mais ce n'est pas toujours le cas.
Ensuite c'est toujours pareil, selon le contexte, on va aller plus ou moin loin dans les détails de la conception.

3 - agenda et répartition des tâches
il est indispensable de se fixer des "mile stone" et de répartir les tâches. Déterminer une durée pour une tâche est très difficile, et seule l'expérience permet de ne pas trop se tromper.

4 - développement d'une version
à chaque mile stone correspond une version. Chaque version implémente une partie des fonctionnalité et spécifie clairement celles qu'elle n'implémente pas.

5 - tests de la version
les tests vont dépendre du contexte. Par exemple, si on a une équipe "qualité" à disposition, les tests seront plus longs et ne seront pas effectués par les développeurs (pratique conseillée mais pas toujours possible).

si ces tests (ou le developpement en lui-même) font ressortir des erreurs de conception ou des oublis, on refait une passe sur la conception.

Ensuite on itère les pas 4 et 5 jusqu'à la fin.


C'est un mix de RUP et de XP.

My cent.

[JolyLoic]

Juste une remarque, j'ai l'impression que nombre de gens utilisent les tests comme un moyen de "valider", triturer, affiner les specs avant de passer à la réalisation. J'ai tendance pour ma part à utiliser la documentation technique, que je rédige avant de coder, pour le même effet.

[Mat007]

J'ai tendance pour ma part à utiliser la documentation technique, que je rédige avant de coder, pour le même effet.

Ça ressemble à quoi ? Tu la rédiges à la main ?
Tu génères du code à partir de la documentation ou il faut synchroniser manuellement la documentation et le code lors des mises à jour ?

MAT.

[JolyLoic]

Non, du tout manuel. Mais je ne parle pas de la documentation de chaque fonction, mais plutôt d'une documentation d'un niveau un peu plus élevé.

En gros, des schémas UML, le texte qui les accompagne pour expliquer les alternatives possibles et les raisons du choix, la description des algos principaux, un mode d'emploi "philosophique" (pour un vector, j'expliquerais la contiguïté de mémoire, la stratégie de croissance (avec démonstration du O(1) amorti), mais pas la syntaxe exacte de push_back)...

Bref, des choses qui restent stables en présence de petits changements dans l'interface.