Euh... si tu le dis. Je t'avoue que tu m'a largué dès que tu as dégainé OCaml, ce qui est assez habituel me concernant (être largué quand je vois du code de language fonctionnel).
A priori, sur le principe, je suis d'accord avec toi, mais... bon: je ne vois pas le rapport avec la performance, qui est l'un des point principaux de l'article que l'on commente.
Bon, j'ai quand même vaguement compris que tu défends l'idée que les interfaces c'est bien pour la compréhension. Je suis d'accord avec ça.
Par contre, ton commentaire ne parle en rien de performance, je vais donc me permettre de compléter avec mon opinion:
Moi, ça me paraît évident, en fait, et je pense même qu'avec des interfaces suffisamment claires, on récupère de la performance tout simplement parce qu'on va éviter de faire plusieurs fois la même opération pour rien, naturellement.
Autrement dit, je pense que d'avoir des algo super performants dans chaque fonction, ben, je m'en fout. De toute façon moi, je suis nul en algo.
Je préfère de loin me concentrer sur l'architecture: ça permets de faire la maintenance plus facilement, et si besoin est, de remplacer, justement, les algo par d'autres mieux adaptés en fonction du contexte.
Dans son exemple, si on a besoin plusieurs fois de la surface d'un carré, on va la calculer a chaque fois. Bonjour la performance... alors qu'avec des classes, aussi pourries soient-elles dans l'exemple qu'il a effectivement piqué à un «défenseur de la POO» (la POO a des soucis a se faire avec ce type de défenseurs...) il serait possible à posteriori de modifier les classes pour ne faire le calcul que lors des modifications des côtés du carrés, rectangle, ... et ce, sans devoir passer au peigne fin quelques dizaines de milliers de lignes de code. Pour les petits projets. On parle bien vite de centaines de milliers, après tout...
[^] # Re: l'héritage et les exemples pourris
Posté par freem . En réponse au lien « Clean code » : performances lamentables. Évalué à 2.
Euh... si tu le dis. Je t'avoue que tu m'a largué dès que tu as dégainé OCaml, ce qui est assez habituel me concernant (être largué quand je vois du code de language fonctionnel).
A priori, sur le principe, je suis d'accord avec toi, mais... bon: je ne vois pas le rapport avec la performance, qui est l'un des point principaux de l'article que l'on commente.
Bon, j'ai quand même vaguement compris que tu défends l'idée que les interfaces c'est bien pour la compréhension. Je suis d'accord avec ça.
Par contre, ton commentaire ne parle en rien de performance, je vais donc me permettre de compléter avec mon opinion:
Moi, ça me paraît évident, en fait, et je pense même qu'avec des interfaces suffisamment claires, on récupère de la performance tout simplement parce qu'on va éviter de faire plusieurs fois la même opération pour rien, naturellement.
Autrement dit, je pense que d'avoir des algo super performants dans chaque fonction, ben, je m'en fout. De toute façon moi, je suis nul en algo.
Je préfère de loin me concentrer sur l'architecture: ça permets de faire la maintenance plus facilement, et si besoin est, de remplacer, justement, les algo par d'autres mieux adaptés en fonction du contexte.
Dans son exemple, si on a besoin plusieurs fois de la surface d'un carré, on va la calculer a chaque fois. Bonjour la performance... alors qu'avec des classes, aussi pourries soient-elles dans l'exemple qu'il a effectivement piqué à un «défenseur de la POO» (la POO a des soucis a se faire avec ce type de défenseurs...) il serait possible à posteriori de modifier les classes pour ne faire le calcul que lors des modifications des côtés du carrés, rectangle, ... et ce, sans devoir passer au peigne fin quelques dizaines de milliers de lignes de code. Pour les petits projets. On parle bien vite de centaines de milliers, après tout...