Discussion :

[zaventem]

Loin de moi l'idée de contredire ce que tu avances, mais c'est un autre cas extrême que tu cites, un projet scolaire ne sera jamais repris/maintenu/étendu ou amené à évoluer. Dans un cadre professionnel, c'est très différent. Il faut donc équilibrer les deux aspects, élégant/extensible et user-friendly/documenté etc.

Je suis entièrement d'accord avec toi, le tout est de trouver un équilibre.

Si j'ai pris cette exemple c'est que depuis dans ma vie prof. j'ai toujours été parfait (ou alors c'est que à chaque fois que mon chef s'est rendu compte que j'avais le temps de me faire plaisir, c'est qu'il ne me chargeait pas assez mais j'aime moins cette version).

Et même dans ce cas-ci, je m'étais fait plaisir en ayant conscience d'aller trop loin (si nous devions construire une usine qui pouvait assembler des PC, la mienne auraient pu assembler n'importe quoi tant qu'on lui fournissait les pièces). Je remercie mes prof de m'avoir donner cette leçon quand les conséquences étaient nulle (car j'ai vu des gens se faire virer pour avoir fait des choses semblables plus tard)

[shenron666]

J'ai l'impression que la plupart des réponses négatives se focalisent sur le fait qu'on finit toujours avec un nombre fini de choix possibles (homme/femme etc).

encore un qui généralise
pour le reste je suis d'accord avec toi, ce n'est pas parcequ'une limite est fixée qu'on ne peut pas faire du générique réutilisable paramétrable etc

[Barsy]

Pour prendre l'exemple du jeu de l'oie, le principe de conception est simple :

Il suffit de créer une classe mère "Case" et des classes filles pour chaque type de case dans le jeu ("CaseRejouer", "CasePuit", "CasePrison", "CaseVide"...) avec dans chacune une méthode "action" permettant de décrire ce que va faire la case en question.
Enfin, le jeu en lui même est représenté par une classe "Jeu" qui contient un tableau d'objets "Case".

En faisant ainsi, je peux faire évoluer simplement mon jeu à tout moment en modifiant le tableau de cases et je peux facilement réaliser mes propres cases supplémentaires. Simple, propre, et respectueux de la règle "0, 1, infini".

Je ne vois pas pourquoi la méthode décrite ci-dessus entrainerait un surcoût par rapport à la méthode bourrin de l'utilisation d'un "switch(maCase)". Ça sert à ça la POO !!
Quand parfois, je dois reprendre des applications d'autres développeurs pour les faire évoluer, j'ai le sentiment que peu de monde maîtrise le concept.

[oca]

la méthode bourrin de l'utilisation d'un "switch(maCase)".

ben moi... j'aime bien le switch case (et spécialement en groovy par exemple)... je le trouve très lisible et souvent plus claire qu'une "patternerie à la GOF" du genre vitrtualAbstractBuilderFactory.createCaseJeuDeLoi(...) (même si je ne suis pas complètement contre l'utilisation des patterns")

Sinon pour la règle, je suis plutôt pas d'accord. je suis trop pragmatique... j'ai trop vu des bouts de code génériques qui sont lent et pire... impossible à maintenir... alors que le but était de pouvoir évoluer justement...

[amaillere]

en fait ce qui me gène le plus dans l'enoncé c'est
"stipule que toute architecture logicielle destinée à un nombre limité d'instances (supérieure à 1) doit être prohibée."

ben il est bien gentil le bonhomme mais c'est pas lui qui va venir coder ma table de réf "sexe" modifiable sous prétexte que ca peut augmenter.(je vous dirai pas comment, c'est sale)

[Virgil Scipion]

En théorie oui.
En pratique aussi, la plupart du temps.

Mais quand on sait que le nombre d'instances sera toujours limité, et que ce nombre est très réduit (le meilleur exemple : 2), pour me simplifier la vie je me base sur un nombre fini d'instance.
Car il est plus simple d'accéder à deux variables plutôt qu'à un tableau.

Mais quand on commence à avoir un nombre plus important, ne serait-ce que 5, alors là oui, c'est mode infini et utilisation de liste.

[Mpolo]

Bein je crois bien que je n'ai rien pigé moi aussi.
Si j'ouvre Internet, c'est une instance ? si dans le même temps j'ouvre Media Player, est-ce une autre instance ?
Mon ordi doté de deux + deux cores est paraît-il de traiter les deux simultanément sans problème.
Maintenant si je conçois une appli qui demande de mettre en route ces deux instances afin qu'une renseigne ou approvisionne l'autre est-ce que je déroge au principe ?
Risque-je des poursuites (je rigole) suis-je ou à côté de la plaque (et là je risque de faire rigoler, donc tant mieux) ?

[Invité]

Dans les logiciels de conception (UML, Merise, etc.) qui sont des logiciels qui ont été pensés pour schématiser n'importe qu'elle architecture de manière générale, on retrouve de manière très présente les trois cas 0,1,infini dans les mutiplicités/cardinalités. Il doit s'agir donc d'une pseudo-règle qui peut être suivie par un grand nombre d'applications.
Par contre, il subsiste évidement des cas très spéciaux, d'ou l'ajout dans ce type de logiciel de petits pour indiquer la valeur que l'on souhaite.

Typiquement, dans une application dédiée à la généalogie, on se retrouve avec un enfant qui a... 2 parents.
Ces cas spéciaux dépendent bien évidemment des contraintes imposées. Car on pourrait naturellement concevoir d'avoir n parents (parents biologiques, parents d'adoption, etc.)
Cependant, ces cas restent rares ou en tous cas, il y a toujours une bonne raison pour laquelle on a choisi cette structure (optimisation, raisons techniques, etc.)

Du coup, je dirais que pour moi, la loi du 0,1,n reste une loi théorique. Et comme chacun sait, la pratique est parfois différente de la théorie

[pseudocode]

Du coup, je dirais que pour moi, la loi du 0,1,n reste une loi théorique. Et comme chacun sait, la pratique est parfois différente de la théorie

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

[el_slapper]

(.../...)Je ne vois pas pourquoi la méthode décrite ci-dessus entrainerait un surcoût par rapport à la méthode bourrin de l'utilisation d'un "switch(maCase)". Ça sert à ça la POO !!
Quand parfois, je dois reprendre des applications d'autres développeurs pour les faire évoluer, j'ai le sentiment que peu de monde maîtrise le concept.

C'est bien pour ça qu'il ne faut pas en abuser. Un switch case, c'est bien plus facile à lire pour un médiocre qu'une encapsulation avec héritage. Et quand vient l'heure de la modif en urgence, nous sommes tous médiocres.

Certes, c'est long et galère à modifier, mais, au final, un type qui n'y comprend pas grand chose y arrivera quand même.(je sens que je vais accumuler les -1 sur ce message, mais tant pis).

[Barsy]

C'est bien pour ça qu'il ne faut pas en abuser. Un switch case, c'est bien plus facile à lire pour un médiocre qu'une encapsulation avec héritage. Et quand vient l'heure de la modif en urgence, nous sommes tous médiocres.

Alors pour l'anecdote :

J'avais une application dans laquelle une liste d'éléments pouvait-être filtrée par le biais de 2 champs. Mon prédécesseur avait développé de la façon suivante :

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
if (txtFiltre1.Text != "" && txtFiltre2.Text == "")
{
	contenuListe = filtreSurChamp1(txtFiltre1.Text);
}
else if (txtFiltre1.Text == "" && txtFiltre2.Text == "")
{
	contenuListe = filtreSurChamp2(txtFiltre2.Text);
}
else if (txtFiltre1.Text != "" && txtFiltre2.Text != "")
{
	contenuListe = filtreSurChamps1et2(txtFiltre1.Text, txtFiltre2.Text);
}
else
{
	contenuListe = tousLesElements();
}

A chaque fois, derrière les méthodes de filtre, il y avait une requete SQL différente.

L'évolution que j'avais à réaliser était d'ajouter un champ de filtre supplémentaire, chose qui, dans un code bien écrit, se fait rapidement.
Aurai-je du dans le cas présent poursuivre sur ce pseudo "switch case" et multiplier la taille par 2 à chaque ajout d'un champ ? Avec 5 champs, j'aurai eu 32 "if.

Et dans le cas du jeu de l'oie, vous feriez un switch avec 59 cases ?

[amaillere]

la, on parle de jeux de l'oie et de switch...
La question était purement théorique. Depuis quand on discute de la validité d'une théorie sur un exemple précis?
enfin en science, hein, en philo on peut

[Kantizbak]

C'est bien pour ça qu'il ne faut pas en abuser. Un switch case, c'est bien plus facile à lire pour un médiocre qu'une encapsulation avec héritage. Et quand vient l'heure de la modif en urgence, nous sommes tous médiocres.

Certes, c'est long et galère à modifier, mais, au final, un type qui n'y comprend pas grand chose y arrivera quand même.(je sens que je vais accumuler les -1 sur ce message, mais tant pis).

oui tu as raison... tu vas accumuler les -1 ^^
Avec une bonne conception, la modif en urgence est d'autant plus simple.
Je prends pour exemple le pattern State/Etat que j'utilise souvent. Il utilise le concept d'héritage à fond et la modification d'une transition ou l'ajout d'un état est extremement simple (la modification du graphe d'état utilisé pour la conception fonctionnelle se retrouve directement dans celui utilisé pour la conception technique ; la modification d'un état ne concerne qu'un état en lui même et pas son contrôleur externe comme on pourrait le faire avec un switch).

Je t'invite (en fait tous) à utiliser le pattern State et là, c'est la révélation.

Après on peut dire que c'est la même chose ("on ne conçoit qu'un nombre fini de cas au final") mais en fait on conçoit pour un nombre infini qui se trouve être un nombre variable de cas finis. Ce qui est différent

[el_slapper]

(.../...)Je t'invite (en fait tous) à utiliser le pattern State et là, c'est la révélation.

ça va être dur, en COBOL . Ca peut être intéressant dans un certain nombre de cas. Mais, crois-tu qu'un médiocre sera capable de rajouter des cas sans tout casser??? C'est ça, mon doute affreux(déjà -3).....

Après on peut dire que c'est la même chose ("on ne conçoit qu'un nombre fini de cas au final") mais en fait on conçoit pour un nombre infini qui se trouve être un nombre variable de cas finis. Ce qui est différent

Là ou on peut le faire, ça peut être sympa. Avec le bémol ci-dessus...

[Kantizbak]

ça va être dur, en COBOL .

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?

<TROLL>
bon bah sinon on comprends pourquoi le COBOL est mort
</TROLL>

[remond]

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

Pourrais tu m'en citer quelques unes ??

[sekaijin]

Pourrais tu m'en citer quelques unes ??

1. mon robot à deux bras et deux jambes il n'y a aucune raison de mettre 1 ou de mettre * il n'y en a que deux de chaque c'est matériellement impossible de lui en mettre plus.
2. pour le déplacement d'un objet dans l'espace j'ai exactement 6 degrés de liberté translation sur les axes des X des Y et des Z rotation sur les axes X, Y et Z.
3. le satellite qui doit partir pour explorer un astéroïde possède exactement 27 propulseur à gaz de positionnement. il n'en aura jamais plus ni moins.
4. mon home cinéma possède 6 HP, un aigu face un caisson basse deux avant et deux arrières.
5. la plaque de cuisson vitrocéramique a exactement 4 point de chauffe.
6. La chaudière de ma résidence à 2 brûleurs, 5 vannes de répartition 2 motopompes.

dans tous ces cas il convient de se poser la question dois-je modéliser avec le nombre exact ou avec *

1. pour le robot espace mémoire oblige dans le microcontrôleur moins on en consomme mieux c'est.
2. pour les degrés de liberté c'est physiquement impossible d'en avoir plus inutile de mettre *
3. pour le satellite c'est de l'embarque comme pour le robot mais ne vais-je pas en construire un autre dans l'avenir ?
4. pour le home cinéma je peux me poser la question de l'avenir n'existera-t-il pas de système plus pourvus ?
5. de même pour les plaque de cuisson j'en aurais-je pas 5 ou 6 dans l'avenir ?
6. pour la chaudière c'est évident suivant l'installation ces quantités peuvent varier.

A+JYT

[pseudocode]

Pourrais tu m'en citer quelques unes ??

La raison la plus courante que je rencontre (et que j'ai déjà cité), c'est que le problème est beaucoup plus simple à résoudre avec un nombre limité et connu d'instances. Faire une conception généraliste avec un nombre illimité ou inconnu rendrait le problème différent, complexe, voir insoluble.



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 )

[remond]

non mais je ne vais certainement pas me contenter d'un jeu avec seulement 3 disques, alors qu'au niveau de la conception ça suffit largement

En tout cas, merci pour vos exemples.

[Kantizbak]

saperlipopette .... suis - je donc le seul à trouver cette discussion ubuesque ?


fallait faire philo les gars !!!

non c'est la base de toute conception
Toi t'aurais pas du faire info ^^