Ca fait longtemps que je n'ai pas fait de Java ou de langage statiquement typé, mais s'il y a bien un truc que j'ai toujours trouvé curieux, c'est ce préfixage des interfaces et des classes abstraites, surtout en Java où on utilise les interfaces à foison pour contourner l'absence d'héritage multiple/mixin. Ok, ça "peut" faciliter la lecture du code, mais durant le court séjour que j'ai passé dans le privé au contact de développeurs Java, j'ai pu remarquer qu'il y avait une sorte de "religion" consistant à créer des interfaces pour absolument tout et n'importe quoi, et de n'utiliser que ces "types" pour les paramètres et valeurs de retour. Du coup, ça n'aide pas plus que ça pour voir *concrètement* (j'insiste sur ce mot) ce que le code fait

C'est le principe de l'interface, ne pas savoir concrètement ce qu'elle fait.
A priori, tu n'as pas à le savoir.

Tu pars du principe que l'implémentation de l'interface que tu utilises sais faire son boulot, tu n'as pas à savoir comment, juste à savoir qu'elle le fait.

L'interface est hyper pratique pour écrire des tests unitaires. Tu ne veux pas tester l'implémentation de l'interface, juste ce que tu reçois ou envoie à l'interface, tu peux faire un Mockup de l'interface et simuler ce qu'elle produit/attend.

C'est pour ça certainement qu'il y avait une interface pour tout et n'importe quoi (enfin, c'est comme ça que nous faisons).

Si les fonctions de l'interface sont bien nommées, le nom de la fonction est censée t'indiquer ce qu'elle fait, et c'est censé te suffire.

Il y a quelques principes de "clean code" pour le nommage des fonctions, et si les objets passés en paramètre sont modifié ou non (et normalement non)

Rien ne t'empêche d'avoir une classe concrète au lieu d'une interface, avec une implémentation de base (voire partielle) et d'utiliser ce type un peu partout (même si, en pratique, tu vas probablement en hériter pour le spécialiser). Je ne vois pas ce qu'une interface apporte de plus qu'une classe (partiellement ou non) abstraite, à part (tout du moins en Java) la possibilité de "greffer" plusieurs interfaces sur une même classe (et donc de "contourner" l'absence d'héritage multiple, au moins au niveau du typage).

Ma remarque portait plutôt sur le fait d'utiliser des interfaces systématiquement partout, à tel point que souvent, les devs écrivaient les classes "concrètes", et puis écrivaient une interface par dessus et utilisaient cette interface pour les références de type. Oui, je comprends l'utilité (en Java), mais non, ce n'est pas une bonne façon de faire et c'est représentatif d'une faiblesse du langage (quand tu commences à faire "systématiquement quelque chose", c'est qu'il y a un souci quelque part, parce que ça pourrait être automatique/automatisé).

Après, je suis certainement biaisée étant un adepte du duck typing de Python. Oui, si c'est "mal écrit et mal documenté", c'est une horreur, mais au lieu d'avoir à écrire des interfaces à tour de bras, j'écris de la documentation (ce qui est mieux). Et avec des projets comme Mypy pour vérifier statiquement le typage grâce aux annotations, on peut pratiquement avoir la confiance du typage statique d'un autre langage, avec l'avantage de la souplesse du système de types de Python.

C'est aussi pour cette raison que je commence à m'intéresser de plus en plus à Typescript d'ailleurs

GuybrushC'est aussi pour cette raison que je commence à m'intéresser de plus en plus à Typescript d'ailleurs

Si t'aime pas Java, je suis pas sûr que tu vas kiffer Typescript

Sinon l'héritage multiple c'est une fractale de mauvais design, l'expérience montre que le "bon" code est plutôt fait de composition et de contrats (SOLID tout ça). Une classe de 40 méthodes qui implémente une interface de 40 méthodes on est d'accord que c'est tout pété, mais c'est pas une faiblesse du langage, c'en est une du développeur
Globalement j'ai l'impression que les best practices de tous les langages tendent à converger.

L'approche de Go est intéressante pour faire tendre vers des interfaces (= contrats) bien séparés.

Pour info les interfaces Java permettent un "genre" de mixins avec les implémentations par défaut. C'est plutôt fait pour gérer les ruptures de compat' (nouvelle méthode dans une interface qui continue à supporter les anciennes implémentations).

FabeSi t'aime pas Java, je suis pas sûr que tu vas kiffer Typescript

Le typage n'est pas facultatif dedans ? Y a de l'inférence, je pense, mais le compilateur ne fait que se plaindre sans bloquer la transpillation non ? Sinon, effectivement, je risque de ne pas apprécier

FabeSinon l'héritage multiple c'est une fractale de mauvais design, l'expérience montre que le "bon" code est plutôt fait de composition et de contrats (SOLID tout ça). Une classe de 40 méthodes qui implémente une interface de 40 méthodes on est d'accord que c'est tout pété, mais c'est pas une faiblesse du langage, c'en est une du développeur

Oui, tout à fait. J'évite autant que possible l'héritage multiple en Python parce que ça pose vite beaucoup de souci (namespace mais aussi les appels multiples à super(x) pour être sûr de "tout couvrir"). Par contre, j'utilise la fonctionnalité syntaxique d'héritage multiple pour composer des mixins entre eux, et ça, c'est vachement pratique Je regrette d'ailleurs qu'il n'y ait pas un support direct pour les mixins (autrement que via l'héritage multiple, qui pose toujours la question de savoir quand appeler la/les méthode(s) parente(s)), comme en Ruby (même si je n'aime pas le fait qu'on puisse déclarer on-the-fly des mixins dans d'autres fichiers, car ça rend la lecture du code bien plus difficile).