Il faut reconnaitre que l'existence des interfaces, et l'interdiction de l'héritage multiple généralisé, pousse à ressentir le LSP à défaut de le comprendre -- ce qui n’empêchera pas des dev Java de définir des listes triées avec un extend sur un liste normale (il n'y avait pas un truc comme ça dans une des premières versions de la lib standard de java d'ailleurs ?).
Pour la notion de contrat, je ne suis pas du tout d'accord avec toi, rimram31. La gestion des contrats est un truc tardif en Java et nécessite l'emploi de préprocesseurs externes. En C++, on a en natif le pattern NVI (impossible à mettre en œuvre au milieu d'un héritage multiple d'interface en Java). Dans les deux cas, il s'agit d'hacks bien loin de la propreté de la solution d'Eiffel. [Si tu veux me vendre un langage OO propre, parle moi à la limite d'Eiffel, voire Ruby, mais non pas de Java]
Après, est-ce que le développeur Java va mieux réfléchir aux interfaces ? Hum ... quand on voit les environnements de dev, et certains frameworks (hibernate, c'est bien ça?) qui poussent à un attribut == un setter + un getter, je dirai que c'est tout le contraire. L'objet n'est toujours pas mieux compris malgré les œillères imposées par le langage -- n'est-ce pas pour ça qu'elles existent d'ailleurs ? [et ho, on est trolldi, et c'est pas moi qui ais commencé]. Pour les développeurs C++, parmi les rares qui restent, s'ils ont le malheur de trainer sur des forums, on va tellement leur casser les pieds avec des notions de design qu'au final ils seront sensibilisés au LSP, à la loi de Déméter, et bien d'autres choses. [parfois je me demande même si nous ne fabriquons, sur les forums, des sortes d'évangélistes des bonnes pratiques C++...]
Partager