Programmation objet : erreur de "casting" ?

La Programmation Orientée Objet a été positionnée comme une évolution positive du codage impératif (C, Cobol…). Un monde nouveau qui ne pouvait qu’être avantageux. A vrai dire, nous n’en sommes plus très sûrs. Même si personne ne remet sérieusement en cause les principes de la POO : urbanisation du code, sécurité via l’encapsulation, maintenabilité plus rationnelle, héritage et polymorphisme, etc, il faut aussi admettre que l’écriture objet peut s’avérer complexe, voire inefficace, si l’on ne maîtrise pas bien les fondamentaux. L’expérience montre par exemple que de nombreux programmeurs n’ont pas réellement compris ce qu’est un héritage, pour le moins en abusent, au point de créer des "cordes à nœuds" difficiles à maintenir. Le sujet n’étant plus tabou, certains chefs de projets déçus, n’hésitent plus à faire état de leurs difficultés et pointent les inconvénients de la POO, sur lesquels nous nous proposons de revenir. Histoire de mieux comprendre pourquoi des nouveaux langages majeurs, tels que Go et Rust, se sont en partie détournés de l’approche. Alors, sommes nous déçus de la POO où s’agit-il simplement des conséquences de l'usure technologique normale d'un concept au départ révolutionnaire.…