J'espère que tu es ironique malgré le "(vraie question)"...
Cette solution impose de surcharger toutes les méthode qui modifient le tableau, ce qui veut dire :
- ralentir toutes les modifications du tableau, un appel surchargé à un coût non-néglgeable quand il est fait régulièrement ce qui est souvent le cas pour les modifications de tableaux ;
- rendre la maintenance très complexe, la personne qui maintien le code du tableau n'est pas forcément au courrant de toutes les classes dérivées.
Tout ça juste pour une solution soit-disant "propre" alors que les valeurs de retour multiple serait bien plus simples et beaucoup moins complexes à gérer et maintenir.
Avec les retours multiple on a une fonction d'une vingtaine de lignes pour laquelle une entrée dans la doc est suffisante et dont la maintenance est simple.
Avec la solution java, on a une base d'un quarantaine de lignes plus quatre ou cinq lignes par fonctions d'acces. La doc deviens beaucoup moins simple et la maintenance est galère car le dev doit surveiller toutes les modif de la classe de base et vérifier qu'il n'y a pas de nouvelles fonctions d'accès à surcharger.
On perd la transparence de l'aspect objet, la fonction minmax deviens bien plus dépendante de l'api exposée par la classe de base.
De plus, au départ la fonction minmax éxiste pour éviter de faire deux fois le coûteux parcours du tableau, mais vu que tous les acces deviennent plus coûteux le gain final est négatif.
[^] # Re: javascript
Posté par beagf . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 4.
Cette solution impose de surcharger toutes les méthode qui modifient le tableau, ce qui veut dire :
- ralentir toutes les modifications du tableau, un appel surchargé à un coût non-néglgeable quand il est fait régulièrement ce qui est souvent le cas pour les modifications de tableaux ;
- rendre la maintenance très complexe, la personne qui maintien le code du tableau n'est pas forcément au courrant de toutes les classes dérivées.
Tout ça juste pour une solution soit-disant "propre" alors que les valeurs de retour multiple serait bien plus simples et beaucoup moins complexes à gérer et maintenir.
Avec les retours multiple on a une fonction d'une vingtaine de lignes pour laquelle une entrée dans la doc est suffisante et dont la maintenance est simple.
Avec la solution java, on a une base d'un quarantaine de lignes plus quatre ou cinq lignes par fonctions d'acces. La doc deviens beaucoup moins simple et la maintenance est galère car le dev doit surveiller toutes les modif de la classe de base et vérifier qu'il n'y a pas de nouvelles fonctions d'accès à surcharger.
On perd la transparence de l'aspect objet, la fonction minmax deviens bien plus dépendante de l'api exposée par la classe de base.
De plus, au départ la fonction minmax éxiste pour éviter de faire deux fois le coûteux parcours du tableau, mais vu que tous les acces deviennent plus coûteux le gain final est négatif.
Bref, mauvaise solution.