java - grails

Escritura explícita en Groovy: a veces o nunca?

Question

[Más tarde: aún no puedo averiguar si Groovy tiene tipografía estática (parece que no la tiene) o si el código de byte generado usando tipificación explícita es diferente (parece que sí lo es). De todos modos, a la pregunta]

Una de las principales diferencias entre Groovy y otros lenguajes dinámicos, o al menos Ruby, es que puedes inactivamente Escriba explícitamente las variables cuando quiera.

Dicho esto, ¿cuándo deberías usar la escritura estática en Groovy? Aquí hay algunas posibles respuestas que puedo pensar:

1. Solo cuando hay un problema de rendimiento. Las variables tipificadas estáticamente son más rápidas en Groovy. (o son? algunas preguntas acerca de este enlace)
2. En las interfaces públicas (métodos, campos) para las clases, para que pueda autocompletar. ¿Es esto posible / verdadero / totalmente incorrecto?
3. Nunca, simplemente desordena el código y anula el propósito de usar Groovy.
4. Sí, cuando sus clases serán heredadas o usadas

No solo me interesa lo que USTEDES, sino lo que es más importante lo que has visto en los proyectos codificados en Groovy. Cual es la norma

Nota: si esta pregunta es de alguna manera incorrecta o si falla algunas categorías de estático-dinámico, avíseme y lo arreglaré.

Answer 1

En mi experiencia, no hay norma. Algunos usan mucho los tipos, otros nunca los usan. Personalmente, siempre trato de usar tipos en las firmas de mi método (para params y valores de retorno). Por ejemplo siempre escribo un método como este.

Boolean doLogin(User user) {
// implementation omitted
}

Aunque podría escribirlo así.

def doLogin(user) {
// implementation omitted
}

Hago esto por estas razones:

1. Documentación : otros desarrolladores (y yo mismo) sabemos qué tipos proporcionará y devolverá el método sin leer la implementación
2. Escriba seguridad : aunque no hay una verificación de tiempo de compilación en Groovy, si doLogin versión estática de doLogin con un parámetro que no es de usuario, fallará de inmediato, por lo que es probable que el problema sea fácil de solucionar. Si llamo a la versión tipificada dinámicamente, fallará algún tiempo después de que se invoque el método, y la causa de la falla puede no ser inmediatamente obvia.
3. Finalización de código : esto es particularmente útil cuando se utiliza un buen IDE (es decir, IntelliJ), ya que incluso puede proporcionar finalización para métodos agregados dinámicamente, como los buscadores dinámicos de la clase de dominio.

También uso tipos bastante dentro de la implementación de mis métodos por las mismas razones. De hecho las únicas veces que no uso tipos son:

1. Realmente quiero apoyar una amplia gama de tipos. Por ejemplo, un método que convierte una cadena en un número también podría convertir una colección o una matriz de cadenas en números
2. ¡Pereza! Si el alcance de una variable es muy corto, ya sé a qué métodos quiero llamar, y no tengo la clase importada, entonces declarar que el tipo parece ser más problemático de lo que vale.

Por cierto, no pondría mucha fe en esa publicación de blog que has vinculado al afirmar que Groovy escrito es mucho más rápido que Groovy sin estilo. Nunca había escuchado eso antes, y no encontré la evidencia muy convincente.

Answer 2

Groovy no admite la escritura estática. Véalo usted mismo:

public Foo func(Bar bar) {
return bar
}
println("no static typing")

Guarde y compile ese archivo y ejecútelo.

Answer 3

He visto información de tipo utilizada principalmente en clases de servicio para métodos públicos. Dependiendo de lo compleja que sea la lista de parámetros, incluso aquí generalmente veo solo el tipo de retorno escrito. Por ejemplo:

class WorkflowService {
....
WorkItem getWorkItem(processNbr) throws WorkflowException {
...
...
}
}

Creo que esto es útil porque explícitamente le dice al usuario del servicio de qué tipo tratará y ayuda con el código de asistencia en IDE.

Answer 4

Trabajé en varios proyectos Groovy y nos ceñimos a tales convenciones:

• Todos los tipos en métodos públicos deben ser especificados.

  public int getAgeOfUser (String userName) {...}

• Todas las variables privadas se declaran usando la palabra clave def .

Estas convenciones te permiten lograr muchas cosas.

En primer lugar, si utiliza la compilación conjunta, su código java podrá interactuar con su código groovy fácilmente. En segundo lugar, tales declaraciones explícitas hacen que el código en grandes proyectos sea más legible y sostenible. Y, por supuesto, la finalización automática también es un beneficio importante.

Por otro lado, el alcance de un método suele ser bastante pequeño, por lo que no es necesario declarar tipos explícitamente. Por cierto, los IDE modernos pueden completar automáticamente sus variables locales incluso si usa defs.