Je viens de lire un des articles de Joel dans lequel il dit:
En général, je dois admettre que j'ai un peu peur des fonctionnalités du langage qui cachent des choses . Quand vous voyez le code
i = j * 5;
… En C, vous savez au moins que j est multiplié par cinq et que les résultats sont stockés dans i.
Mais si vous voyez le même extrait de code en C ++, vous ne savez rien. Rien. La seule façon de savoir ce qui se passe réellement en C ++ est de savoir ce que sont les types i et j, ce qui pourrait être déclaré ailleurs. C'est parce que j est peut-être d'un type
operator*
surchargé et qu'il fait quelque chose de terriblement spirituel lorsque vous essayez de le multiplier.
(C'est moi qui souligne.) Peur des fonctionnalités linguistiques qui cachent des choses? Comment pouvez-vous avoir peur de cela? Cacher des objets (également appelés abstraction ) n’est-il pas l’ une des idées clés de la programmation orientée objet? Chaque fois que vous appelez une méthode a.foo(b)
, vous n'avez aucune idée de ce que cela pourrait faire. Vous devez trouver quels types a
et quels types b
sont quelque chose qui pourrait être déclaré ailleurs. Alors devrions-nous nous débarrasser de la programmation orientée objet, car elle cache trop de choses au programmeur?
Et en quoi est-il j * 5
différent de j.multiply(5)
ce que vous pourriez avoir à écrire dans un langage qui ne prend pas en charge la surcharge des opérateurs? Encore une fois, il vous faudrait connaître le type de méthode j
et jeter un coup d'œil à l'intérieur de la multiply
méthode, car bon à savoir, il j
pourrait s'agir d'un type qui possède une multiply
méthode qui fait quelque chose de terriblement spirituel.
"Muahaha, je suis un mauvais programmeur qui nomme une méthode multiply
, mais ce qu'elle fait est totalement obscure et non intuitive et n'a absolument rien à faire avec la multiplication des choses." Est-ce un scénario que nous devons prendre en compte lors de la conception d'un langage de programmation? Ensuite, nous devons abandonner les identifiants des langages de programmation sous prétexte qu’ils pourraient être trompeurs!
Si vous voulez savoir ce que fait une méthode, vous pouvez regarder la documentation ou jeter un coup d'œil à l'intérieur de la mise en œuvre. La surcharge d'opérateur n'est que du sucre syntaxique, et je ne vois pas du tout en quoi cela change le jeu.
S'il te plaît, éclaire-moi.