Et maintenant, il y a même mieux entre ces deux modules : algébriquement, ces deux structures sont totalement isomorphes (comme pour Descartes et Bessel dans la fable de Reynolds). Autrement dit, elles sont complétement équivalentes pour l'utilisateur et, en tant qu'implémenteur, je peux passer de l'une à l'autre sans perturber aucunement le code client, à la condition de respecter le principe Code should not know about the internals of objects it’s working with. ;-)
C'était ma compréhension naïve de la POO, mais le contact avec la STL de C++ a mis mes certitudes à rude épreuve. Par exemple, conceptuellement, ça m'a beaucoup gêné de ne pas avoir accès à des fonctions inefficaces pour certains containers. Par exemple, vector::push_front(). C'est une opération inefficace sur un vecteur, certes, mais ça empêche l'abstraction (en particulier, ça rend le benchmarking très difficile, alors qu'il y a des algos pour lesquels les performances relatives de différents containers mériterait d'être testé empiriquement). En gros, avec les containers de la STL, tu es obligé de savoir comment ils sont implémentés, parce que tu n'as accès qu'à une liste restreinte de méthodes en fonction de l'efficacité algorithmique des opérations. Est-ce qu'il n'y a pas là des principes qui se contredisent, et que les concepteurs de la STL ont choisi de trancher dans un sens sans laisser l'utilisateur décider?
[^] # Re: l'héritage et les exemples pourris
Posté par arnaudus . En réponse au lien « Clean code » : performances lamentables. Évalué à 3.
C'était ma compréhension naïve de la POO, mais le contact avec la STL de C++ a mis mes certitudes à rude épreuve. Par exemple, conceptuellement, ça m'a beaucoup gêné de ne pas avoir accès à des fonctions inefficaces pour certains containers. Par exemple, vector::push_front(). C'est une opération inefficace sur un vecteur, certes, mais ça empêche l'abstraction (en particulier, ça rend le benchmarking très difficile, alors qu'il y a des algos pour lesquels les performances relatives de différents containers mériterait d'être testé empiriquement). En gros, avec les containers de la STL, tu es obligé de savoir comment ils sont implémentés, parce que tu n'as accès qu'à une liste restreinte de méthodes en fonction de l'efficacité algorithmique des opérations. Est-ce qu'il n'y a pas là des principes qui se contredisent, et que les concepteurs de la STL ont choisi de trancher dans un sens sans laisser l'utilisateur décider?