IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

La règle "zéro, un ou infini" serait omniprésente dans le développement logiciel

  1. #81
    Membre averti
    Profil pro
    Inscrit en
    janvier 2004
    Messages
    319
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2004
    Messages : 319
    Points : 417
    Points
    417
    Par défaut
    Citation Envoyé par pseudocode Voir le message

    Y a-t-il une bonne raison de modéliser plus de 3 piquets pour ce jeu ?

    (En particulier si c'est pour avoir plus de piquets que de disques )
    Dans la vraie vie, dans l'IT, celui qui a voulu la tour de hanoi peut changer d'avis ; demander à avoir la même chose mais en fait le nombre de disque change en fonction du jour de l'année.
    Arf. Du coup de "c'est pas possible/c'est cher", on a "aucun problème" avec un conception à x disques.

    Disons c'est une question d'anticipation du changement. Et puis d'intérêt aussi à continuer à développer. Je continue mon exemple de vécu dans l'IT.

    Je le dis de suite, une fois que mon travail est bien fait, je ne demande rien, je passe à autre chose. Et je suis fier de rappeler mes anciens collègues pour savoir que mon projet marche bien. Donc j'essaie de bien concevoir car c'est ma passion et c'est tout.

    Mais dans tout projet, il arrive un moment où on veut faire plus/différemment.
    Le métier voudrait qu'on ait tout prévu ; la cupidité voudrait qu'on ait rien prévu pour pouvoir tout refaire et rester 3 ans de plus en poste.

    Alors, elle est là la réalité? Finalement avec une mauvaise conception, on se rendrait indispensable? et avec une bonne, le projet vit sans toi?

    donc une bonne conception n'est pas dans notre intérêt à tous?

  2. #82
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 834
    Points
    15 834
    Par défaut
    Citation Envoyé par Kantizbak Voir le message
    Dans la vraie vie, dans l'IT, celui qui a voulu la tour de hanoi peut changer d'avis ; demander à avoir la même chose mais en fait le nombre de disque change en fonction du jour de l'année.
    Arf. Du coup de "c'est pas possible/c'est cher", on a "aucun problème" avec un conception à x disques.
    Avec l'expérience, je deviens de plus en plus adepte du KISS (Keep it simple, Stupid!). Conception minimale pour répondre au problème posé. J'ai remarqué qu'il est plus simple d'avoir une conception robuste si on reste dans le minimalisme. Il est également plus simple d'en changer en cas d'évolution.

    Alors certes, on peut aussi "parier" sur les futurs évolutions en faisant une conception flexible, évolutive, paramétrable. Mais pour ma part, cela pose 2 problèmes :

    1. Les changements demandés par le client sont souvent "fonctionnels" et rarement "techniques". Moralité, il ne suffit pas de modifier une constante dans un fichier de config pour résoudre le problème.

    2. Ces architectures sont plus complexes/longues à développer. Cela crée une "résistance" au changement, car on n'a pas vraiment envie de sacrifier le travail déjà effectué

    Bref, j'évite de faire de la sur-conception "au cas où" ca pourrait servir.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  3. #83
    Membre chevronné
    Homme Profil pro
    /
    Inscrit en
    février 2003
    Messages
    431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Belgique

    Informations professionnelles :
    Activité : /

    Informations forums :
    Inscription : février 2003
    Messages : 431
    Points : 2 168
    Points
    2 168
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    Avec l'expérience, je deviens de plus en plus adepte du KISS (Keep it simple, Stupid!). Conception minimale pour répondre au problème posé. J'ai remarqué qu'il est plus simple d'avoir une conception robuste si on reste dans le minimalisme. Il est également plus simple d'en changer en cas d'évolution.
    Je te rejoins entièrement


    Citation Envoyé par pseudocode Voir le message
    1. Les changements demandés par le client sont souvent "fonctionnels" et rarement "techniques". Moralité, il ne suffit pas de modifier une constante dans un fichier de config pour résoudre le problème.
    Pour reprendre l'exemple du nombre de jambes d'un robot, admettons qu'on ai conçu le système pour pouvoir étendre ce nombre avec un simple paramètre, so what? Il faudra de toute manière revoir entièrement le principe même de la marche

  4. #84
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 614
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 614
    Points : 31 085
    Points
    31 085
    Par défaut
    Citation Envoyé par Kantizbak Voir le message
    Quelle idée de faire du cobol aussi !
    Sans faire de POO, il y a des tableaux quand même?! je ne connais pas COBOL mais tu bien avoir la possibilité de faire des boucles, etc. et d'avoir des traitements sur des structures de données finies?
    Disons que tout est fini. On peut faire un tableau
    ou peut faire un tableau de taille variable
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    01 TABLEAU OCCURS 0 TO 25 DEPENDING ON TAILLE-TABLEAU.
    mais on ne peut pas faire sans dimensionner, genre les collections. Donc il faut borner tout algorithme. La seule chose non bornée dans le code, c'est quand on lit/écrit un fichier/base.

    L'avantage immense, c'est qu'à l'exécution, l'usage mémoire est fixe, et determiné dès la compilation. Ca facilite grandement l'exploitation.
    L'inconvénient, tu l'as souligné, c'est que ça interdit certains algorithmes élégants. Tout ce qui nécéssite une allocation dynamique de mémoire est banni(le DEPENDING ON prépare déjà les 25 occurences, juste le code ne pourra en lire que 10 si TAILLE-TABLEAU est à 10)

    Citation Envoyé par Kantizbak Voir le message
    <TROLL>
    bon bah sinon on comprends pourquoi le COBOL est mort
    </TROLL>
    en continuant le troll : il y a encore plein de gens qui cherchent des ressources en cobol. Si ça survit, c'est qu'il reste quelques qualités. Dont la lisibilité par des béotiens.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  5. #85
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 484
    Points : 5 307
    Points
    5 307
    Par défaut
    Citation Envoyé par pseudocode
    1. Les changements demandés par le client sont souvent "fonctionnels" et rarement "techniques". Moralité, il ne suffit pas de modifier une constante dans un fichier de config pour résoudre le problème.

    2. Ces architectures sont plus complexes/longues à développer. Cela crée une "résistance" au changement, car on n'a pas vraiment envie de sacrifier le travail déjà effectué
    Je ne suis pas d'accord du tout.

    C'est justement le but de la conception de pouvoir s'adapter plus facilement aux évolutions. Si tu passes plus de temps à concevoir ton logiciel pour ensuite ne plus avoir envie de le modifier, c'est que la méthodologie employée laisse à désirer.

    Prenons un exemple simple (j'aime beaucoup les exemples). le jeu de l'oie dont j'ai posé les bases de conception ici : http://www.developpez.net/forums/d10...l/#post5612877

    Si le client demande une évolution fonctionnelle, par exemple, l'ajout ou l'inversion de cases dans le jeu, je n'ai qu'à modifier mon "Array" dans la classe Jeu et à inverser mes éléments, en ajouter, retirer, à volonté et cela en quelques minutes.

    Et encore mieux, si le client vient me voir en me disant que finalement, il veut faire un Monopoly, j'ai déjà tout mon ensemble "Jeu/Case" de prêt. Il n'y a qu'à implémenter de nouveaux enfants de la classe Case et à adapter le tableau de Cases en conséquence.

    Je ne vois pas en quoi une conception soignée empêcherait la mise en place d'évolutions. Au contraire !! Quand je développe, je conçois dans le but de pouvoir réaliser rapidement le maximum d'évolutions. Alors certes, en début de projet ça nécessite de poser le stylo, de prendre une feuille de papier et d'écrire quelques schémas avant de se lancer dans le développement, mais ça fonctionne très bien.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  6. #86
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    4 178
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 178
    Points : 9 082
    Points
    9 082
    Par défaut
    je suis entièrement d'accord

    même si ça parait lourd au début une bonne conception assure facilité de maintenance évolution portabilité

    j'ai aussi les exemples.
    prenez votre outils de mail s'il est développé avec la méthode

    il y a de forte chance que le code de connexion soit dans la fonction de connexion que la relève de courrier dans la fonction de relève etc.

    du coup si moi en tant que client je demande le support d'un nouveau protocole de transport de courrier il va être difficile de l'implémenter.

    si au contraire l'outil est bien conçu et qu'il à séparé le protocole des fonctionnalités de l'application l'ajout d'un protocole est l'affaire de quelques heures.

    mieux l'impact sur le logiciel étant bien ciblé la phase de test sera plus facile en ayant pensé l'architecture avec un approche plugin pour les protocole il n'y a même pas de test unitaire d'interface à faire coté soft (mail) juste côté protocole. la phase de test d'intégration est claire et réduite, il devient facile de cibler les test de recette. et le déploiement en est lui aussi facilité.

    A+JYT

  7. #87
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 834
    Points
    15 834
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Prenons un exemple simple (j'aime beaucoup les exemples). le jeu de l'oie dont j'ai posé les bases de conception ici : http://www.developpez.net/forums/d10...l/#post5612877

    Si le client demande une évolution fonctionnelle, par exemple, l'ajout ou l'inversion de cases dans le jeu, je n'ai qu'à modifier mon "Array" dans la classe Jeu et à inverser mes éléments, en ajouter, retirer, à volonté et cela en quelques minutes.

    Et encore mieux, si le client vient me voir en me disant que finalement, il veut faire un Monopoly, j'ai déjà tout mon ensemble "Jeu/Case" de prêt. Il n'y a qu'à implémenter de nouveaux enfants de la classe Case et à adapter le tableau de Cases en conséquence.
    heu... oui... Mais quel est le rapport avec la règle "0,1,infinity" qui nous préoccupe ici ?

    Le KISS ne préconise pas de faire des conceptions pourries sous prétexte qu'elles sont simples, si c'est ce que tu voulais démontrer. Le KISS dit seulement que lorsque plusieurs alternatives valables sont possibles, il faut choisir la plus simple.

    Dans ton exemple de jeu de l'oie, il parait évident de partir sur une modélisation objet pour les cases. En l'absence d'autres alternatives pertinentes, c'est ce choix qu'il faut prendre.

    Par contre, tu n'as pas forcément besoin dans un premier temps de séparer la modélisation du "plateau" et celle de la "partie". L'alternative d'avoir une seule classe qui modélise entièrement le jeu est plus simple. Tu pourras toujours faire cette séparation plus tard lorsque tu auras la demande fonctionnelle qui le nécessite (par exemple gérer différents types de plateaux).
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  8. #88
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 484
    Points : 5 307
    Points
    5 307
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    Excellent !! Il y a pas mal de truc que l'on retrouve dans certains projets
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  9. #89
    Membre chevronné
    Homme Profil pro
    /
    Inscrit en
    février 2003
    Messages
    431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Belgique

    Informations professionnelles :
    Activité : /

    Informations forums :
    Inscription : février 2003
    Messages : 431
    Points : 2 168
    Points
    2 168
    Par défaut
    Imaginons un système automatisé où un véhicule doit franchir une porte: si la porte est fermée, il attend patiemment qu'elle s'ouvre pour passer.

    Prévoyez-vous pour la porte un système à deux états (ouvert/fermé) ou à quatre (ouvert/en train de s'ouvrir/fermé/en train de se fermer) au cas où cela pourrait-être utile un jour?

  10. #90
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 834
    Points
    15 834
    Par défaut
    Citation Envoyé par zaventem Voir le message
    Imaginons un système automatisé où un véhicule doit franchir une porte: si la porte est fermée, il attend patiemment qu'elle s'ouvre pour passer.

    Prévoyez-vous pour la porte un système à deux états (ouvert/fermé) ou à quatre (ouvert/en train de s'ouvrir/fermé/en train de se fermer) au cas où cela pourrait-être utile un jour?
    Tout dépend du niveau de conception. En conception générale (système) je ne modélise pas les états transitoires. Par contre en conception détaillée (logiciel) ça peut avoir son utilité, notamment dans ce cas précis où un automate d'état semble une bonne approche.


    Edit: c'est vrai que ca n'a pas trop de rapport avec la news.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  11. #91
    Membre confirmé
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    329
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : octobre 2004
    Messages : 329
    Points : 600
    Points
    600
    Par défaut
    Ça me semble complètement hors de propos vis à vis de la "règle" comme question

  12. #92
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 484
    Points : 5 307
    Points
    5 307
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    heu... oui... Mais quel est le rapport avec la règle "0,1,infinity" qui nous préoccupe ici ?

    Le KISS ne préconise pas de faire des conceptions pourries sous prétexte qu'elles sont simples, si c'est ce que tu voulais démontrer. Le KISS dit seulement que lorsque plusieurs alternatives valables sont possibles, il faut choisir la plus simple.

    Dans ton exemple de jeu de l'oie, il parait évident de partir sur une modélisation objet pour les cases. En l'absence d'autres alternatives pertinentes, c'est ce choix qu'il faut prendre.

    Par contre, tu n'as pas forcément besoin dans un premier temps de séparer la modélisation du "plateau" et celle de la "partie". L'alternative d'avoir une seule classe qui modélise entièrement le jeu est plus simple. Tu pourras toujours faire cette séparation plus tard lorsque tu auras la demande fonctionnelle qui le nécessite (par exemple gérer différents types de plateaux).
    Le rapport est qu'avec le modèle de conception que je propose, il est possible d'adapter pour une infinité de cases. C'est dans la continuité de ce qui a été dit dans la discussion sur les premières pages. (respect de l'aspect "infini" de la règle)

    Ensuite, quand tu dis que dans mon exemple, c'est évident, je peux t'assurer que ça n'est pas si vrai que ça. Beaucoup de développeurs partiraient directement sur un modèle de conception à 59 cases sans essayer de le rendre modulable. Par exemple, en écrivant directement dans le code quelque chose du style "if (joueur.position == 59) gagne(joueur)". Si demain, la case arrivée est la case 60, il faudra, dans le code, partir à la chasse de ces lignes en dur.

    Pour ce qui est de séparer le "plateau" avec la "partie", c'est vrai qu'il est possible de les imaginer dans une même classe. Après, c'est sur ce genre de point qu'il faut prendre un stylo et gribouiller pour réfléchir un peu : est ce que c'est vraiment plus couteux de les séparer, et comment se fait cette séparation.

    Citation Envoyé par zaventem
    Imaginons un système automatisé où un véhicule doit franchir une porte: si la porte est fermée, il attend patiemment qu'elle s'ouvre pour passer.

    Prévoyez-vous pour la porte un système à deux états (ouvert/fermé) ou à quatre (ouvert/en train de s'ouvrir/fermé/en train de se fermer) au cas où cela pourrait-être utile un jour?
    Alors on peut penser dans le cas du portail qu'il est possible d'ajouter des Etats. Donc prévoir un système de type "infini". Il y a les états "ouvert/fermé" mais comme tu dis, il y a aussi les états "ouverture/fermeture". Et on peut tout à fait supposer qu'il y ait d'autres états, par exemple : début de course/fin de course (en fin de course, le portail doit ralentir pour ne pas heurter la butée). Bref, si on prévoit dès le départ que l'application peut gérer plusieurs états, il sera beaucoup plus simple de la faire évoluer dans le cas où il faudrait l'adapter à des systèmes de portail différents.

    Enfin, il n'y a pas de hors sujet ici, il y a une règle de conception qui a été énoncée, et il est normal de voir dans quelle mesure celle-ci peut s'appliquer à des cas concrets.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  13. #93
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 834
    Points
    15 834
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Le rapport est qu'avec le modèle de conception que je propose, il est possible d'adapter pour une infinité de cases. C'est dans la continuité de ce qui a été dit dans la discussion sur les premières pages. (respect de l'aspect "infini" de la règle)

    Ensuite, quand tu dis que dans mon exemple, c'est évident, je peux t'assurer que ça n'est pas si vrai que ça. Beaucoup de développeurs partiraient directement sur un modèle de conception à 59 cases sans essayer de le rendre modulable. Par exemple, en écrivant directement dans le code quelque chose du style "if (joueur.position == 59) gagne(joueur)". Si demain, la case arrivée est la case 60, il faudra, dans le code, partir à la chasse de ces lignes en dur.
    Hum. Pas vraiment d'accord sur la raison.

    Pour ma part, la création d'une classe "case" est liée à la modélisation du problème : 1 plateau avec des cases ayant des caractéristiques différentes.

    Ca n'a pas vraiment à voir avec une possibilité d'extensibilité future. C'est juste que la méthodologie objet nous amène à créer une classe case (qui pourra être spécialisée) et de multiples instances. Le nombre d'instance est égale au nombre de cases. Ce nombre étant constant durant tout le jeu, la solution la plus simple (KISS) est de créer un tableau de taille fixe.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  14. #94
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 484
    Points : 5 307
    Points
    5 307
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    Hum. Pas vraiment d'accord sur la raison.

    Pour ma part, la création d'une classe "case" est liée à la modélisation du problème : 1 plateau avec des cases ayant des caractéristiques différentes.

    Ca n'a pas vraiment à voir avec une possibilité d'extensibilité future. C'est juste que la méthodologie objet nous amène à créer une classe case (qui pourra être spécialisée) et de multiples instances. Le nombre d'instance est égale au nombre de cases. Ce nombre étant constant durant tout le jeu, la solution la plus simple (KISS) est de créer un tableau de taille fixe.
    C'est justement parce que la méthodologie objet met en pratique la règle 0,1,infini. Quand tu écris le schéma UML de ton application, les liens entre les objets sont du type 0,1,*.

    Pour ce qui est du tableau, bien entendu que la taille sera fixée à 59, il faut bien qu'à un moment donnée, on définisse le nombre de cases présentes dans le jeu. Mais dans ce cas, tu écriras quelque chose comme new Case[NB_CASES] ou NB_CASES sera une constante que tu pourras modifier simplement.
    Ou alors, quelque chose dans le style "new Case[] {new CaseDepart(), new CaseRejouer(), new CaseVide()...}" ce qui reviendra au même et qui évitera d'avoir à définir la constante de taille puisque celle-ci sera implicite suivant le nombre d'éléments que tu auras placé dans le tableau.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  15. #95
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 834
    Points
    15 834
    Par défaut
    Citation Envoyé par Barsy Voir le message
    C'est justement parce que la méthodologie objet met en pratique la règle 0,1,infini. Quand tu écris le schéma UML de ton application, les liens entre les objets sont du type 0,1,*.

    Pour ce qui est du tableau, bien entendu que la taille sera fixée à 59, il faut bien qu'à un moment donnée, on définisse le nombre de cases présentes dans le jeu. Mais dans ce cas, tu écriras quelque chose comme new Case[NB_CASES] ou NB_CASES sera une constante que tu pourras modifier simplement.
    Si la règle "0-1-*" devait être appliquée, tu créerais une liste extensible plutôt qu'un tableau de taille fixe.

    Tout comme moi, tu as bien senti que la meilleure solution est d'utiliser un tableau de taille fixe (constante = NB_CASES). Pourquoi ? Parce que dans ce problème tu as, tout comme moi, remarqué que le nombre de case n'était pas "inifini" mais égal à 59. Bref, ton choix de conception provient du fait que le problème se modélise par une association de 1 plateau avec 59 cases.

    Ton choix aurait surement été complètement différent s'il s'agissait d'un plateau de jeu d'un MMORPG avec des maps potentiellement infinies. Auquel cas la modélisation aurait vraiment été 1 plateau avec une infinité de cases, et la solution certainement pas un tableau de taille fixe.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  16. #96
    Membre éclairé Avatar de Code62
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    novembre 2008
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Conseil

    Informations forums :
    Inscription : novembre 2008
    Messages : 162
    Points : 898
    Points
    898
    Par défaut
    Excepté que seule la définition du tableau est fixée par l'implémentation (voir pages précédentes, tout le monde est à peu près d'accord sur la différence entre conception et implémentation), tout le reste du logiciel respecte la règle et est capable de gérer un tableau d'un nombre variable (mais non "infini", tout le monde est d'accord là dessus aussi) d'éléments...

    La conception générale du logiciel respecte donc la règle énoncée.
    "Le premier venu peut écrire du code qu'un ordinateur peut comprendre. Les bons programmeurs écrivent du code que les humains peuvent comprendre."
    "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
    (Martin Fowler)

  17. #97
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 484
    Points : 5 307
    Points
    5 307
    Par défaut
    Citation Envoyé par Code62 Voir le message
    Excepté que seule la définition du tableau est fixée par l'implémentation (voir pages précédentes, tout le monde est à peu près d'accord sur la différence entre conception et implémentation), tout le reste du logiciel respecte la règle et est capable de gérer un tableau d'un nombre variable (mais non "infini", tout le monde est d'accord là dessus aussi) d'éléments...

    La conception générale du logiciel respecte donc la règle énoncée.
    Exactement !!

    Au final, le but de l'application c'est quand même de faire un jeu de l'oie. Donc il y aura forcément un moment où il faudra définir les cases et leur nombre.

    et puis j'avais même proposé la solution suivante qui évite d'avoir à déclarer la constante NB_CASES :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    public class Plateau
    {
    	private Case[] arrCases = new Case[]
    	{
    		new CaseDepart(),
    		new CaseVide(),
    		new CaseRejouer(),
    		new CasePuit(),
    		
    		[...],
    		
    		new CaseArrivee()
    	};
    	
    	[...]
    	
    }
    Le tableau ci-dessus est de taille fixe, mais celle-ci est implicite.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  18. #98
    Membre averti
    Profil pro
    Inscrit en
    janvier 2004
    Messages
    319
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2004
    Messages : 319
    Points : 417
    Points
    417
    Par défaut
    Citation Envoyé par zaventem Voir le message
    Imaginons un système automatisé où un véhicule doit franchir une porte: si la porte est fermée, il attend patiemment qu'elle s'ouvre pour passer.

    Prévoyez-vous pour la porte un système à deux états (ouvert/fermé) ou à quatre (ouvert/en train de s'ouvrir/fermé/en train de se fermer) au cas où cela pourrait-être utile un jour?
    ça ne sert à rien dans l'immédiat évidemment! mais au moins, on peut traiter un ensemble infini d'état possible de la porte. Et modifier la liste des états disponibles par la suite.

    Disons que plutôt que de traiter un état directement dans un contrôleur en fonction de l'élément d'une énumération, on peut traiter des objets qui contiennent le traitement (c'est l'esprit du pattern State en poo...)

    Pour donner un exemple dans la vraie vie, tu peux avoir une porte et un système de commande.
    Si tu dois ajouter un bouton à ton système de commande, tu change la porte???
    Pour moi c'est ce qu'il faut éviter.

    Avec une conception souple et faiblement couplée (c'est ça aussi le Keep It Simple ; par ailleurs, je trouve l'ajout du "kiss" assez moyen, juste un moyen de troller comme un ado), ça permettera d'ajouter facilement "en panne" ou "absente"

    Bon alors je le vois très bien en Java, mais dans d'autres langages non ce serait impossible? je le vois très bien en C par exemple;

    L'idée c'est de prévoir un traitement infini mais par la suite un nombre fini de cas pouvant varier

    Mais bien entendu, ça ne s'applique pas toujours à tout dans la vraie vie!!! parfois il faut faire des choix en fonction des couts, surtout dans la fin de vie d'un produit. Mais pas avant!

  19. #99
    Membre à l'essai
    Profil pro
    Inscrit en
    octobre 2002
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2002
    Messages : 13
    Points : 18
    Points
    18
    Par défaut
    A chaque règle ses exceptions :
    Il existe nombre de cas d'automates impossible (et prouvé comme tel) à réaliser avec un nombre d'états finis ce qui impose de définir une limite arbitraire pour le système fini qui en découle.
    La problématique de la limite optimale peut souvent se résoudre par un système linéaire où les critères variés peuvent aller du coût ou de la portée minimale souhaitée, plutôt qu'un choix à "pile ou face".

  20. #100
    Nouveau Candidat au Club
    Inscrit en
    décembre 2010
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : décembre 2010
    Messages : 1
    Points : 1
    Points
    1
    Par défaut regle-zero-infini-serait-omnipresente-developpement-logiciel
    Bonjour,

    J'émets un doute sur cette règle. Comment pouvons-nous comprendre l'utilisation des Pool ( pattern pool - cf commons-pool Apache) par rapport à cet règle?
    N'y a t-il pas un paradoxe en cette règle et ce pattern ?

    Cordialement,
    Luc BONAMI

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo