¿Puedes tener demasiado "dinámico" en idiomas dinámicos?

Question

En los últimos meses he estado haciendo una transición de Java a Groovy y puedo apreciar muchos de los beneficios que trae: menos código, cierres, constructores, MOP que al final hace posible el uso de frameworks como Grails, facilidad con la burla al escribir pruebas, etc.

Sin embargo, mis compañeros de trabajo me han "acusado" de que mi código no es suficientemente groovy. Es decir, sigo declarando tipos para mis parámetros y campos, uso herencia y polimorfismo en lugar de tipado de pato, etc. Me parece que en estas situaciones no solo es dinámico vs. estático, sino también paradigma dinámico frente a orientado a objetos tipo de dilema En esos casos, todavía tiendo a preferir OO. Siento que el paradigma OO tiene un gran valor en su premisa básica al permitirle abstraer y relacionar las construcciones de su código con conceptos particulares del mundo real.

tanto, aquí están las preguntas particulares que necesito ayudar con:

1. ¿Debo declarar tipos para mi parámetros, campos, etc?

2. ¿Debo declarar el bloqueo de código como cierre cuando lo haga un método simple?

3. Cuándo debería usar pato escribiendo en lugar de envío dinámico polimórfico. Por ejemplo, en groovy puedo hacer animal. "$ Action"() o def animal; animal.action(), en lugar de Animal animal = new Dog(); animal.action(). Puedo ver el problema primero en el contexto del principio de Open-Closed, pero ¿hay alguna otra razón para preferir el polimorfismo de OO?

4. ¿Cuándo debo usar interfaces en Groovy (si es que alguna vez lo hizo)?

Estoy seguro de que existen otros dilemas similares que no pude escribir. También creo que estas preguntas son válidas no solo para groovy, sino para cualquier otro lenguaje dinámico. ¿Cuál es su opinión?

Answer 1

.1. ¿Debo declarar tipos para mis parámetros, campos, etc.?

Tiendo a declarar tipos en clases que se usan como parte de una API pública, cosas que otros desarrolladores consumirán mucho, o donde me gustaría un poco de ayuda de Autocompletar adicional de IntelliJ. De lo contrario, 'def' las cosas.

.2. ¿Debería declarar el bloqueo de código como cierre cuando lo haga un método simple?

Utilizo métodos a menos que sea algo que planeo pasar como una variable. Aunque existe el operador de eliminación de referencias del método "foo. & bar", la mayoría de los desarrolladores no lo conocen y se sienten confundidos cuando se topan con él. También utilizo los cierres cuando es un pequeño fragmento de código que queda claro en un método más grande en lugar de ponerlo en su propio método con fines descriptivos.

.3. ¿Cuándo debo usar el tipado de pato en lugar del envío dinámico polimórfico? Por ejemplo, en groovy puedo hacer animal. "$ Action"() o def animal; animal.action(), en lugar de Animal animal = new Dog(); animal.action(). Puedo ver el problema primero en el contexto del principio de Open-Closed, pero ¿hay alguna otra razón para preferir el polimorfismo de OO?

Solo uso el formulario animal "$ action"() cuando necesito ese nivel de indirección porque el nombre del método varía en función de la ruta de ejecución del código (más a menudo durante la metaprogramación pesada). Yo uso animal animal = nuevo perro(); animal.action() cuando quiero la ayuda del IDE con el autocompletado, o ese nivel de documentación es útil para la claridad del código (y no me afecta la verbosidad adicional que puede ser obvia o restrictiva).

.4. ¿Cuándo debería usar interfaces en Groovy (si alguna vez)?

Raramente los uso. Podría verlos usándolos principalmente como documentación de los campos esperados para una llamada API pública, o posiblemente como una interfaz de marcador para ayudar a distinguir un conjunto de clases de otro desde una perspectiva de metaprogramación. Son mucho menos útiles en Groovy que en Java.

Answer 2

Creo que con Groovy deberías favorecer la forma más simple de hacer algo, y recurrir a las funciones de groovier solo cuando la situación lo requiera. (Como cuando se escriben macros o se crean métodos multimétodos en Clojure, si se encuentra buscando esas herramientas mucho, debería cuestionarse). Su enfoque prudente me parece bien, posiblemente sus compañeros de trabajo estén un poco intoxicados con su poder recién descubierto. . (No sería la primera vez.)

Lo bueno de tener un lenguaje flexible como Groovy es que puede comenzar con el enfoque cauteloso como si prefiriese saber que tiene alternativas más poderosas para recurrir cuando lo necesite. ellos. Ya sabes, "lo más simple que podría funcionar".

Más específicamente prefiriendo el tipado de pato sobre las interfaces y no molestarse con los tipos en los parámetros parece que podría ser una buena cosa, puede hacer mucho más fácil el suministro de simulacros a las pruebas.

Answer 3

Todo se reduce a lo que las personas se sienten cómodas. Me gusta usar declinaciones de tipo y llamadas a métodos porque me siento cómodo con Java. El código que escribo debe ser mantenido por personas sin mucha experiencia en programación dinámica, así que lo mantendré cerca del código Java normal a menos que haya una buena razón para usar una función avanzada de groovy. Parece que su grupo debe crear estándares de codificación que intenten explicar cuándo se deben usar las características específicas de Groovy.

Answer 4

Esto no siempre es una opinión popular, pero creo que cuanto más explícito y claro sea el código, mejor.

No me gusta construcciones que dejan adivinar exactamente lo que está pasando ...

que trabajé durante un año en Ruby y no le gustó en absoluto. No digo que no tenga lugares en los que sobresalga, solo digo que realmente me gusta mantener las cosas limpias y explícitas, y no sentía que Ruby tuviera ese objetivo.

Una cosa que sí sabré con certeza: la cantidad de tipeo que hagas no equivale a la velocidad de desarrollo general. Es cierto que una base de código complicada con muchos códigos repetidos hace que el desarrollo sea muy lento, pero simplemente reducir lo que escribe sin eliminar la duplicación es inútil, y escribir un código más largo, más claro y más explícito generalmente será más rápido (sobre el duración del proyecto) que el mismo código escrito en un lenguaje escueto y menos formal.

Si no cree que escribir no tenga relación con la velocidad de desarrollo, la próxima vez que lance un proyecto cuente el número de líneas de código y divida por los días-hombre pasados ​​(incluyendo depuración y pruebas). En otras palabras, cuánto código se tipeó al día. Encontrará que el resultado es un número muy pequeño: en realidad, escribir código es una parte muy pequeña de cualquier proyecto de software.

Answer 5

SÍ

-

NO

¿Se da cuenta que no hay una respuesta real a esta pregunta?

Answer 6

Existen dos tipos dominantes de lenguajes orientados a objetos.

Las lenguas en el Simula 67 la familia, tales como C++ y Java, a favor de las variables de tipo estático, compiladores y enlazadores, y vtables método.

Los idiomas en la familia Smalltalk, como Ruby, favorecen las variables de tipo dinámico, la interpretación y la transmisión de mensajes en lugar de las tablas de punteros a las funciones.

Ambos están orientados a objetos, pero muy diferente toma el concepto de orientación a objetos.