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

Citation:

---

Envoyé par pseudocode

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 :mrgreen:)

---

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?

Citation:

---

Envoyé par Kantizbak

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. :D

Citation:

---

Envoyé par pseudocode

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 :ccool:

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.

---

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 :roll:

Citation:

---

Envoyé par Kantizbak

Quelle idée de faire du cobol aussi :mrgreen: !
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

Code:

---

01 TABLEAU OCCURS 10.

---

ou peut faire un tableau de taille variable

Code:

---

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

<TROLL>
bon bah sinon on comprends pourquoi le COBOL est mort :mrgreen:
</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.

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.

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 http://www.risacher.com/la-rache/zfiles//logo.png

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

Citation:

---

Envoyé par Barsy

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).

Citation:

---

Envoyé par sekaijin

http://www.risacher.com/la-rache/zfiles//logo.png

---

Excellent !! Il y a pas mal de truc que l'on retrouve dans certains projets :aie:

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?

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?

---

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. ;)

Ça me semble complètement hors de propos vis à vis de la "règle" comme question :roll:

Citation:

---

Envoyé par pseudocode

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.

Citation:

---

Envoyé par Barsy

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.

Citation:

---

Envoyé par pseudocode

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.

Citation:

---

Envoyé par Barsy

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.

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.

Citation:

---

Envoyé par Code62

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 !! :ccool:

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:

---

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.

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?

---

ç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!

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".

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