La règle "zéro, un ou infini" serait omniprésente en génie logiciel,

Conception certes. Mais Conception Logicielle. Dans le but au final d'être implémenté dans un logiciel. Logiciel codé dans un langage informatique... limité (binaire, octet, ...)

Je fais partie de ceux qui aiment bien conceptualiser un problème, mais il ne faut pas perdre de vue l'objectif final. Une solution universelle c'est bien. Une solution optimale, c'est pas mal non plus.

C'est clairement un problème de technique pure vs métier.

Je suis entièrement d'accord avec la règle énoncée. D'un point de vue purement conceptuel, elle est correcte, et je préfère m'y conformer le plus souvent possible.

Maintenant, l'informatique doit s'adapter au métier:

- Nous avons des machines aux capacités finies: les objectifs de performances obligent à limiter le nombre maximal d'éléments traités.
- Les règles de gestion établies par le métier limitent souvent les ensembles à des quantités finies (et ça apparaît dans les specs). Il n'est pas toujours possible d'aller outre.

Oui, j'étais aussi de cette avis dans mes jeunes années.

Je pensais que la meilleure solution était la plus générale, la plus extensible, la plus réutilisable, la plus paramétrable, etc. Avec le temps, je me suis rendu compte que la meilleure solution était souvent la plus simple.

Pour moi, c'est surtout une "rule of thumb" (principe général) de conception.

Dans la pratique ca signifie que lorsque je modélise une association avec une multiplicité 2, 3, ... (ou n'importe quelle valeur finie > 2), je pose mon crayon et je me demande s'il y a une bonne raison pour mettre une valeur "en dur" au lieu de mettre "*".

Une conception "sans limite" ne veut pas dire une implémentation sans prise en compte des contraintes techniques.

Simplement, a la conception on considère l'infini, à l'implémentation on pose une limite à cet infini, une limite souvent déclarée en tant que constante, qu'énumération, etc...

Ainsi, on a un calendrier à 7j dont 5 travaillé, si demain ca change, on a juste à changer la valeur de la constante dans le code pour faire évoluer la limite à travers tout le logiciel et hop, ca fonctionne.

Tout ce qui est dit ici, c'est qu'en phase de conception on fait on ne dit pas "un jeu de l'oie à 65 cases", on dit "un jeu de l'oie à NB_CASES".
Après, à l'implémentation du écrit "NB_CASES = 65", pas de problème, si demain ca change, il n'y a qu'a faire évoluer cette constante, le reste ne change pas. Puisque tout le reste à été conçut pour un nombre inconnu de cases, alors si ca marche pour un nombre inconnus ca veut dire que ca marche quelque soit le nombre.

Par contre si à la conception tu te dis "il y a 65 cases", tu conserveras ce nombre en tête pour tous les autres choix de conceptions et du coup tu va amener des limitations là où il n'y en avait pas, sans même te rendre compte. Par exemple, pour la conception du format de sauvegarde d'une partie, tu va te dire que tu as besoin uniquement de 65 entiers pour représenter les 65 cases. Si demain ca devient 52, ton format de fichier de sauvegarde devient inutilisable, incompatible, etc... Alors que si tu avait pris un nombre inconnu, tu aurai pensé au fait d'indiquer dans le fichier le nombre de cases et donc conserver un code compatible quelque soit le nombre de cases.
Tu va te poser le même problème à l'implémentation, car en lisant ton cahier des charges tu va lire "65 cases" et du coup tu va écrire en dur "65" dans ton code partout où tu en as besoin. Résultat, si demain ce nombre change, il faut repasser partout dans le code et tu t'expose à un risque de changement profond.

Oui, plutôt d'accord avec toi, cependant il y a bel et bien une différence entre infini et inconnu. Celle évoquée par pseudocode.

Gérer une quantité infinie signifie que tu prend en compte qu'il n'y a pas de fin. Tu ne peux donc pas référencer la fin d'une collection puisqu'elle est infinie.
Tu ne peux pas non plus la parcourir bêtement car il n'y a pas de fin à ce parcourt.

C'est donc tout de même assez différent d'une quantité finie mais non connue au moment de la conception, car même si elle n'est pas connue elle est comptable. Il y aura donc une fin référençable à ta collection, un milieu dans ta liste, etc...

Donc oui, faire un algo gérant une infinité permettra aussi de gérer un ensemble fini. Cependant il ne sera probablement pas modélisé de la même façon qu'un algo qui gère une quantité finie mais inconnue.

A mon avis il y a une différence de vocabulaire comme il y en as entre la physique et les mathématiques. L'infini n'existe qu'en mathématique pure. En conception on parle "d'infini" quand on quantifie par "*". Mais comme il a été dit un peu plus haut, le "*" signifie plutôt "plusieurs" et non pas infini.

C'est vrai que la règle "Zéro, Un ou Plusieurs" me plait déjà plus.

Mais pour reprendre mon post #3, les solutions à un problèmes de "Job Shop" sont plus faciles à concevoir en fixant précisément le nombre des entités. Si on garde cette valeur en inconnue, on arrive a des algorithmes généraux horriblement complexes et surtout difficilement prouvables. Alors qu'avec un nombre connu, on peut lister exhaustivement tous les cas possibles et prouver que ca marchera tout le temps.

Cela dit il est vrai que c'est un cas particulier, mais c'est celui que je rencontre en ce moment. Et puis, comme le dit wikipedia, c'est une "rule of thumb" et pas une vérité absolue.

Je n'ai pas dis le contraire. Je ne me souviens pas avoir écrit qu'en physique l'infini n'existe pas.J'ai juste évoqué les différence de vocabulaire entre les physiciens et les mathématiciens car les réalités d'un domaine ne sont pas celle d'un autre. Je me souviens des débats animés que ca provoquait entre mon prof de physique appliqué (électronique) et mon prof de maths quand j'étais au lycée (bien que j'en ai complètement oublié le sujet exacte).

C'est surement en grande partie à cause de cette réflexion qu'on se retrouve si souvent face à des problèmes tels que la pénurie d'IPv4, la limitation de taille de fichier à 4Go sur le FAT32, etc...
Des limitations pour lesquelles on s'est surement dit qu'on atteindrait jamais ces limites...
Et puis c'est un coup dur pour l'innovation si on part du principe qu'on inventera jamais dérivé des échec sur une grille de taille différente.