> crade sur le long terme et de pas evolutif pour un sou
faut voir, j'ai plutôt tendancer à penser qu'un code simple _immédiatement_ est justement plus facile à faire évoluer car il est beaucoup moins complexe à comprendre et moins source de problème.
Mais combien de programmes sont inutilement compliqués derrière des "mais si dans x années qqn code un truc non voulu, non prévu et si il le fait pas exactement comme il faut, ne respecte pas les conventions, etc" ?
C'est bien de vouloir prévoir les cas, mais combien ne se produiront _jamais_ alors que ça aura complexifié le code ?
sinon, pour le getMinMax ecart type toussa, j'ai pas vu la solution (pourtant si chère aux programmeurs java) je prend eclipse refactor toussa et hop rulez ! le fait que j'ai utilisé ailleurs ou non mon minmax est automatiquemnt trouvé / modifié / etc
> Quand a l'appel surcharge a add() sur la collection, je me gausse, on parle de setter un booleen la, une ligne de code, une petite affectation toute simple, si t'es rendu a ce niveau d'optimisation, elle est belle ta vie
Là je pense que t'as pas du saisir ce que je disais. Je n'ai rien contre le fait de rajouter un booléen mais contre le fait de devoir surcharger _toutes_ les méthodes de modification de ma classe.
Si je rajoute une méthode de modification dans ma classe mère alors il _faut_ que je la surcharge dans ma classe fille.
Et toi qui parle de maintenance / évolutivité à qq années, c'est bien pire que de savoir comment je pourrai un jour rajouté un écart type
C'est typiquement le genre de chose qui sera oublié et là l'intégralité des résultats de mon getMinMax sera faux et pour comprendre d'où ça vient rapidement...
[^] # Re: javascript
Posté par CrEv (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 1.
faut voir, j'ai plutôt tendancer à penser qu'un code simple _immédiatement_ est justement plus facile à faire évoluer car il est beaucoup moins complexe à comprendre et moins source de problème.
Mais combien de programmes sont inutilement compliqués derrière des "mais si dans x années qqn code un truc non voulu, non prévu et si il le fait pas exactement comme il faut, ne respecte pas les conventions, etc" ?
C'est bien de vouloir prévoir les cas, mais combien ne se produiront _jamais_ alors que ça aura complexifié le code ?
sinon, pour le getMinMax ecart type toussa, j'ai pas vu la solution (pourtant si chère aux programmeurs java) je prend eclipse refactor toussa et hop rulez ! le fait que j'ai utilisé ailleurs ou non mon minmax est automatiquemnt trouvé / modifié / etc
> Quand a l'appel surcharge a add() sur la collection, je me gausse, on parle de setter un booleen la, une ligne de code, une petite affectation toute simple, si t'es rendu a ce niveau d'optimisation, elle est belle ta vie
Là je pense que t'as pas du saisir ce que je disais. Je n'ai rien contre le fait de rajouter un booléen mais contre le fait de devoir surcharger _toutes_ les méthodes de modification de ma classe.
Si je rajoute une méthode de modification dans ma classe mère alors il _faut_ que je la surcharge dans ma classe fille.
Et toi qui parle de maintenance / évolutivité à qq années, c'est bien pire que de savoir comment je pourrai un jour rajouté un écart type
C'est typiquement le genre de chose qui sera oublié et là l'intégralité des résultats de mon getMinMax sera faux et pour comprendre d'où ça vient rapidement...