¿Cuáles son las ventajas de los objetos complementarios de Scala frente a los métodos estáticos?

50

Scala no tiene una palabra clave estática , sino que tiene una funcionalidad similar a través de objetos complementarios. Detrás de escena, los objetos complementarios se compilan en clases que tienen métodos estáticos, por lo que todo esto es azúcar sintáctico. ¿Cuáles son las ventajas de esta elección de diseño? Desventajas? ¿Otros lenguajes tienen construcciones similares?

Comportamiento
fuente

Respuestas:

49

Aquí hay algunas razones, que pueden ser más o menos convincentes para usted, según sus propias preferencias:

  1. No lo descarte simplemente por ser "azúcar sintáctico". Si bien puede decir que algo es solo azúcar sintáctico, después de todo es el azúcar que endulza su vida, como programador y bebedor de café o té.

  2. Singletons: cada Scala objectes inherentemente un singleton. Teniendo en cuenta que en el mundo de Java, las personas están implementando singletons de todo tipo de formas diferentes y la mayoría de las veces terminan cometiendo algún error en su implementación, no se puede cometer un error tan simple como eso en Scala. Escribir en objectlugar de hacerlo lo classconvierte en un singleton y listo.

  3. Acceso a métodos estáticos: se puede acceder a los métodos estáticos en Java desde los objetos. Por ejemplo, suponga que tiene una clase Ccon un método estático fy un objeto cde tipo C. Entonces deberías llamar C.f, pero Java te permite (aunque con una advertencia) usar c.f, lo que cuando vienes del fondo de Scala realmente no tiene ningún sentido, porque los objetos no tienen un método frealmente.

  4. Separación clara: en Java puede mezclar atributos y métodos estáticos y no estáticos en una clase. Si trabaja disciplinado, esto no se convierte en un problema, sin embargo, si usted (o alguien más para el caso) no lo hace, entonces termina con partes estáticas y no estáticas entrelazadas y es difícil saberlo de un vistazo rápido qué es estático y qué no. En Scala, todo lo que se encuentra dentro del objeto complementario no forma parte de los objetos de tiempo de ejecución de la clase correspondiente, sino que está disponible desde un contexto estático. Viceversa, si está escrito dentro de una clase, está disponible para instancias de esa clase, pero no desde un contexto estático. Esto se vuelve especialmente oneroso en Java, una vez que comienza a agregar bloques de inicializador estáticos y no estáticos a su clase. Esto puede llegar a ser muy difícil de comprender en términos de orden de ejecución dinámico.

  5. Menos código: no es necesario agregar la palabra estática a todos y cada uno de los atributos o métodos de una forma object, de modo que el código sea más conciso (de hecho, no es realmente una ventaja importante).

Las desventajas son mucho más difíciles de encontrar. Se podría argumentar que las partes estáticas y no estáticas deben estar juntas, pero están separadas por el concepto Scala de objetos complementarios. Por ejemplo, puede parecer extraño tener un diagrama de clase, pero luego terminar creando dos cosas en el código y analizar qué atributo va a dónde.

Franco
fuente
1
También leí que las estadísticas no pertenecen a un software puro de OOP. Por ejemplo, cuando necesite un comportamiento estático, use una clase propia y cree un objeto (singleton), que gestione el comportamiento (potencialmente) estático de los objetos de otra clase.
K ..
1
"Escribir un objeto en lugar de una clase lo convierte en un singleton y listo". No me importan mucho los Singletons, pero debo admitir que la franqueza de este "azúcar sintáctico" en particular tiene cierto encanto.
Ed Hastings
3
Ninguno de los puntos del 1 al 5 (e incluso todos juntos) necesita un verdadero objeto complementario en tiempo de ejecución para implementarse. Todos ellos podrían convertirse fácilmente en azúcar sintáctica pura, con cero impacto en el tiempo de ejecución. La única razón real para tener un objeto complementario en tiempo de ejecución se da en la respuesta de Alexey Romanov.
mas.morozov
"Las desventajas son mucho más difíciles de encontrar". ¿Actuación? Acceder a un método de objeto genera ifnonnullbytecode, etc., en comparación con simplemente invokeStatic.
Eduardo Pareja Tobes
33

Una ventaja más es que objects puede implementar interfaces / rasgos, a diferencia de los métodos estáticos.

Alexey Romanov
fuente
8
Creo que esta es la principal diferencia entre un objeto complementario y una clase con métodos estáticos. Un objeto complementario es polimórfico y se puede pasar como argumento a los métodos que esperan una interfaz / rasgo.
dcastro
4

Los objetos complementarios son el primer lugar en el que se buscan implicidades, después de eso, scala mira Predef y luego en declaraciones explícitas de "importación" en ese archivo fuente en particular.

No soy lo suficientemente hábil como para saber si el lenguaje o las bibliotecas de Java proporcionan algún mecanismo comparable.

Gene T
fuente