¿Qué quiso decir Rich Hickey cuando dijo: "Toda esa especificidad [de interfaces / clases / tipos] mata su reutilización!"

No he visto la presentación completa de Rich Hickey, pero si lo entiendo correctamente y, a juzgar por lo que dice sobre la marca de 29 minutos, parece estar discutiendo sobre tipos de la reutilización. Él está usando el término "interfaz" a la ligera como un sinónimo de "tipo llamado", lo que tiene sentido.

Si tiene dos entidades { "name":"John" } de tipo Person y { "name": "Rover" } de tipo Dog , en Java-land probablemente no puedan interoperar a menos que compartan una interfaz común o ancestro (como Mammal , que significa escribir más código). Así que las interfaces / tipos aquí son "eliminando su reutilización": aunque Person y Dog tienen el mismo aspecto, uno no se puede usar de manera intercambiable con el otro, a menos que escriba un código adicional para admitirlo. Tenga en cuenta que Hickey también hace bromas sobre proyectos en Java que necesitan muchas clases ("¿Quién aquí ha escrito una aplicación Java utilizando solo 20 clases?"), Lo que parece ser una consecuencia de lo anterior.

Sin embargo, en los idiomas "orientados a valores", no asignará tipos a esas estructuras; son solo valores que comparten la misma estructura (en mi ejemplo, ambos tienen un campo name con un valor de String) y, por lo tanto, pueden interoperar fácilmente, por ejemplo. se pueden agregar a la misma colección, pasar a los mismos métodos, etc.

En resumen, todo esto parece ser algo relacionado con igualdad estructural vs igualdad explícita de tipo / interfaz . A menos que me haya perdido algo de las partes del video que no he visto todavía :)

Es probable que se refiera al hecho básico de que una interfaz no puede ser instanciada. No puedes reuse una interfaz. Solo puede implementar código que lo admita, y cuando escribe código para una interfaz no se puede reutilizar.

Java tiene un historial de proporcionar marcos de muchas API que toman una interfaz como argumentos, pero el equipo que desarrolló la API nunca implementa una amplia gama de clases para que pueda reutilizar con esas interfaces.

Es como un marco de GUI que tiene una interfaz IWindow para un cuadro de diálogo, y luego puedes agregar interfaces IButton para los controles. Excepto, nunca te dieron una buena clase Button que implementa IButton . Así que te quedas creando el tuyo.

Los marcos abstractos que tienen una amplia gama de clases básicas que proporcionan funcionalidades básicas son más reutilizables, y eso funciona mejor cuando esas clases abstraídas son accesibles para aquellos que usan el marco.

Los desarrolladores de Java comenzaron a hacer esto donde sus capas de API solo expusieron interfaces . Podría implementar esas interfaces, pero nunca podría reutilizar las clases del desarrollador que implementó esas interfaces. Es algo así como un estilo de desarrollo de API de capa y daga.

Creo que la diapositiva 13 en su presentación ( El valor de los valores ) ayuda a comprender esto:

  

Valores

     

• No necesita métodos      
  • Puedo enviarle valores sin código
      y tu estas bien
    
  

Mi entendimiento es que Hickey sugiere que si necesito, por ejemplo, duplicar el valor que me enviaste, simplemente escribo un código que parece

    MyValue = Double(YourValue)

Verás, el código anterior es el mismo, independientemente del valor de clase que hayas enviado: una especie de reutilización perfecta .

Ahora, ¿cómo se vería esto en el lenguaje que tiene objetos e interfaces?

    Doublable MyValue = YourValue.Double()

oh espera! ¿Qué pasa si YourValue no implementa Doublable ? no es que no se pueda duplicar, puede ser perfectamente pero ... ¿qué pasa si no hay un método Double ? (¿qué pasa si hay un método llamado say TwiceAsMuch ?)

Uh oh tenemos un problema. YourValue.Double no funcionará, ya no se puede reutilizar . Por mi lectura de la diapositiva anterior, esto es sobre lo que Hickey quiso decir cuando dijo: "¡Todas esas interfaces matan su reutilización!"

Usted ve, las interfaces asumen que los objetos se pasan "junto con sus métodos", junto con el código que opera en estos. Para usar objetos, uno necesita entender cómo invocar ese código, a qué método llamar.

Cuando falta el método esperado, existe un problema, aunque semánticamente , la operación deseada tiene mucho sentido para un objeto. Como se indica en la presentación, los valores no necesitan los métodos necesarios ("Puedo enviarte valores sin código y estás bien"), lo que permite escribir código para tratarlos de manera genérica.

Nota al margen: la noción de pasar por valores sin código de alguna manera me recuerda a un patrón de peso mosca en POO.

  

^{un objeto que minimiza el uso de la memoria al compartir la mayor cantidad de datos posible con otros objetos similares; es una forma de usar objetos en grandes cantidades cuando una representación repetida simple usaría una cantidad inaceptable de memoria ... Los objetos de peso mosca son, por definición, objetos de valor . La identidad de la instancia del objeto no tiene ninguna consecuencia, por lo que dos instancias de peso mosca del mismo valor se consideran iguales ...}

Los usos de peso mosca que he visto por lo general seguían el mismo enfoque de eliminar el código (métodos, interfaces) de los objetos y pasar cosas como, bueno, valores sin código , esperando que se reciban El código tiene los medios necesarios para operar en estos.

Esto se siente bastante como en la diapositiva, "los valores no necesitan métodos. Puedo enviarte valores sin código y estás bien".

En un (es decir, mi) ideal, las clases e interfaces mundiales siempre describirían el comportamiento, pero el hecho es que con demasiada frecuencia simplemente terminan describiendo datos. Sólo ayer vi el video de alguien que construyó una clase llamada BankAccount que no era más que un int glorificado (de hecho, fue mucho menos útil que un int , por lo tanto, "mató" la reutilización que habría tenido si simplemente se hubiera dejado como int ), todo en nombre del diseño "bueno". La cantidad de código, sudor y lágrimas desperdiciadas en reinventar continuamente las representaciones de datos en espiral es asombrosa; Si no está utilizando los datos de una manera significativa, deje que sea.

Ahora, esta es la etapa en la que Rich Hickey se contenta con echar al bebé con el agua del baño y decir que todos debemos ir a vivir a la tierra de los valores (un vecino del reino de los sustantivos). Creo, por un lado, que la OOP puede y de hecho promueve la reutilización (y, lo que es más importante, la capacidad de descubrimiento, que me parece que carece de programación funcional) cuando se emplea con criterio. Si está buscando un principio de POO que capte mejor esta tensión, creo que podría ser enlace (que por supuesto es un primo cercano de Demeter)