Qu'est-ce que Rich Hickey voulait dire quand il a dit: "Toute cette spécificité [des interfaces / classes / types] tue votre réutilisation!"

Dans 29 minutes, dans son discours « La valeur des valeurs » de Rich Hickey, qui suscite la réflexion, il parle de la surcharge d’un langage tel que Java et fait une déclaration du type «Toutes ces interfaces tuent la réutilisation». Que veut-il dire? Est-ce vrai?

Dans ma recherche de réponses, j'ai croisé:

• Le principe de moindre connaissance AKA La loi de Demeter qui encourage les interfaces API hermétiques. Wikipedia répertorie également certains inconvénients.

• La crise vestimentaire impériale de Kevlin Henney affirme que l’objectif approprié est de ne pas réutiliser.

• Discuter de Jack Diederich dans " Stop Writing Classes " qui va à l'encontre de la sur-ingénierie en général.

Clairement, tout ce qui est écrit assez mal sera inutile. Mais comment l'interface d'une API bien écrite empêcherait-elle l'utilisation de ce code? Tout au long de l’histoire, il existe des exemples de produits fabriqués dans un but particulier et utilisés pour autre chose . Mais dans le monde du logiciel, si vous utilisez quelque chose dans un but pour lequel il n'a pas été conçu, cela se brise généralement.

Je cherche un bon exemple d'une bonne interface empêchant une utilisation légitime mais involontaire de certains codes. Est-ce que ça existe? Je ne peux pas l'imaginer.

Je n'ai pas visionné l'intégralité de la présentation de Rich Hickey, mais si je le comprends bien, et d'après ce qu'il dit à propos de la barre des 29 minutes, il semble se disputer au sujet des types qui tuent la réutilisation. Il utilise vaguement le terme "interface" comme synonyme de "type nommé", ce qui a du sens.

Si vous avez deux entités { "name":"John" }de type Personet { "name": "Rover" }de type Dog, elles ne peuvent probablement pas interopérer en Java-land à moins qu'elles ne partagent une interface ou un ancêtre commun (comme Mammal, ce qui signifie écrire plus de code). Donc, les interfaces / types ici "tuent ta réutilisation": même si, Personet qu’ils se Dogressemblent, l’un ne peut pas être utilisé de façon interchangeable, à moins d’écrire du code supplémentaire pour supporter cela. Remarque Hickey plaisante également sur les projets en Java nécessitant beaucoup de classes ("Qui ici a écrit une application Java utilisant seulement 20 classes?"), Ce qui semble être une conséquence de ce qui précède.

Dans les langages "axés sur les valeurs", toutefois, vous n'affecterez pas de types à ces structures; ce sont juste des valeurs qui partagent la même structure (dans mon exemple, elles ont toutes deux un namechamp avec une valeur String) et peuvent donc facilement interopérer, par exemple, elles peuvent être ajoutées à la même collection, transmises aux mêmes méthodes, etc.

En résumé, tout cela semble être quelque chose sur l' égalité structurelle vs type explicite / l' égalité d'interface . Sauf si j'ai oublié quelque chose dans les extraits de la vidéo que je n'ai pas encore visionnés :)

Il fait probablement référence au fait fondamental qu'une interface ne peut pas être instanciée. Vous ne pouvez pas reuseune interface. Vous ne pouvez implémenter que du code qui le prend en charge, et lorsque vous écrivez du code pour une interface, il n'y a pas de réutilisation.

Java a l'habitude de fournir des frameworks de nombreuses API prenant une interface en argument, mais l'équipe qui a développé l'API n'implémente jamais un large éventail de classes que vous pouvez réutiliser avec ces interfaces.

C'est un peu comme un framework d'interface graphique qui a une IWindowinterface pour une boîte de dialogue et vous pouvez ensuite ajouter des IButtoninterfaces pour les contrôles. Sauf qu'ils ne vous ont jamais donné une bonne Buttonclasse qui implémente IButton. Donc, il ne vous reste plus qu'à créer les vôtres.

Les frameworks abstraits qui ont un large éventail de classes de base fournissant des fonctionnalités de base sont plus réutilisables et fonctionnent mieux lorsque ces classes abstraites sont accessibles à ceux qui utilisent le framework.

Les développeurs Java ont commencé à faire cette chose où leurs couches d'API exposées uniquement interfaces. Vous pouvez implémenter ces interfaces, mais vous ne pouvez jamais réutiliser les classes du développeur qui a implémenté ces interfaces. C'est un peu comme un style de développement d'API avec une cape et une dague.

Je pense que la diapositive 13 de sa présentation ( La valeur des valeurs ) aide à comprendre ceci:

Valeurs

• Pas besoin de méthodes
  • Je peux vous envoyer des valeurs sans code
    et tout va bien

D'après ma compréhension, Hickey suggère que si je dois, par exemple, doubler la valeur que vous m'avez envoyée, j'écris simplement du code ressemblant à

    MyValue = Double(YourValue)

Vous voyez, le code ci-dessus est le même, peu importe la valeur que vous avez envoyée - une sorte de réutilisation parfaite .

Maintenant, à quoi cela ressemblerait-il dans le langage ayant des objets et des interfaces?

    Doublable MyValue = YourValue.Double()

Oh, attendez! Et si YourValuene met pas en œuvre Doublable? non pas que cela ne puisse pas être doublé, ce pourrait être parfaitement mais ... et s'il n'y avait pas de méthode Double ? (et s'il y a une méthode appelée say TwiceAsMuch?)

Euh oh on a un problème. YourValue.Doublene fonctionnera pas, il ne peut plus être réutilisé . D'après ma lecture de la diapositive ci-dessus, c'est à propos de ce que Hickey voulait dire quand il disait: "Toutes ces interfaces tuent la réutilisation!"

Vous voyez, les interfaces supposent que les objets sont transmis "avec leurs méthodes", ainsi que le code qui les exploite. Pour utiliser des objets, il faut comprendre comment appeler ce code, quelle méthode appeler.

Lorsque la méthode attendue est manquante, il y a un problème, même si sémantiquement , l'opération souhaitée est parfaitement logique pour un objet. Comme indiqué dans la présentation, les valeurs n'ont pas besoin de méthodes ("je peux vous envoyer des valeurs sans code et tout va bien"), ce qui permet d'écrire du code les traitant de manière générique.

Note latérale: la notion de transmission de valeurs sans code me rappelle en quelque sorte un motif de poids mouche dans la POO.

^{un objet qui minimise l'utilisation de la mémoire en partageant autant de données que possible avec d'autres objets similaires; c'est une façon d'utiliser des objets en grand nombre lorsqu'une représentation répétée utiliserait une quantité de mémoire inacceptable ... Les objets Flyweight sont par définition des objets de valeur . L’identité de l’instance d’objet n’ayant pas d’importance, deux instances Flyweight de même valeur sont considérées comme égales ...}

Les utilisations Flyweight que j'ai observées suivaient généralement la même approche consistant à supprimer le code (méthodes, interfaces) des objets et à leur transmettre des informations, ainsi que des valeurs sans code , en s'attendant à ce que le code reçu dispose des moyens nécessaires pour les utiliser.

Cela ressemble beaucoup à la diapositive: "Les valeurs n'ont pas besoin de méthodes. Je peux vous envoyer des valeurs sans code et tout va bien".

Dans un monde idéal (c’est-à-dire), les classes et les interfaces décrivent toujours le comportement, mais le fait est que trop souvent, elles ne décrivent que des données. Pas BankAccountplus tard qu'hier, j'ai regardé la vidéo de quelqu'un qui a construit une classe dite qui n'était rien de plus qu'une glorifiée int(en fait, elle était beaucoup moins utile qu'un int, "tuant" ainsi la réutilisation que j'aurais eue si elle avait été laissée comme telle int), tout cela au nom du «bon» design. La quantité de code, de sueur et de larmes gaspillée pour réinventer continuellement les représentations alambiquées des données est stupéfiante; si vous n'utilisez pas les données de manière significative, laissez-les simplement.

C'est à ce stade que Rich Hickey se contente de jeter le bébé avec l'eau du bain et de dire que nous devrions tous aller vivre au pays des valeurs (un voisin du royaume des noms). Je pense, par contre, que la POO peut et doit promouvoir la réutilisation (et surtout la découvrabilité, que je trouve insuffisante en programmation fonctionnelle) si elle est utilisée judicieusement. Si vous recherchez un principe de POO qui capture le mieux cette tension, je pense que cela pourrait être http://c2.com/cgi/wiki?TellDontAsk (qui est bien sûr un proche cousin de Demeter)