Scala no tiene una palabra clave static , sino que tiene una funcionalidad similar a través de los 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áctica. ¿Cuáles son las ventajas de esta elección de diseño? Desventajas? ¿Otros lenguajes tienen construcciones similares?
Aquí hay algunas razones, que pueden ser más o menos convincentes para usted, dependiendo de sus propias preferencias:
No lo descarte simplemente por ser "azúcar sintáctica". Si bien puede decir que algo es solo azúcar sintáctica, es, después de todo, el azúcar que endulza su vida, como programador tan bien como un bebedor de café o té.
Singletons: cada Scala object es inherentemente un singleton. Teniendo en cuenta que, en el mundo de Java, las personas están implementando singletons de diferentes maneras y la mayoría de las veces terminan cometiendo un error en su implementación, no puede cometer un error tan simple como el de Scala. Escribir object en lugar de class lo convierte en un singleton y listo.
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 C con un método estático f y un objeto c de tipo C . Luego, debería llamar a C.f , pero Java le permite (aunque con una advertencia) usar c.f , que cuando viene del fondo de Scala realmente no tiene ningún sentido, porque los objetos sí lo hacen. no tengo un método f en realidad.
Separación clara: en Java puede combinar atributos y métodos estáticos y no estáticos en una clase. Si trabajas de forma disciplinada, esto no se convierte en un problema; sin embargo, si tú (o alguien más) no lo hace, entonces obtienes partes intercaladas estáticas y no estáticas y es difícil decirlo de un vistazo. Lo que es estático y lo que 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, pero está disponible desde un contexto estático. Viceversa, si está escrito dentro de una clase, está disponible para las 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 inicialización 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. Es mucho más claro en Scala, donde se inicializa el objeto complementario de arriba a abajo y luego se hace lo mismo para la clase en caso de que se cree un objeto de tiempo de ejecución.
Menos código: no es necesario agregar la palabra static a todos y cada uno de los atributos o métodos en un object , por lo que el código es más conciso (de hecho, no es un código). ventaja prominente realmente).
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 tiene que crear dos cosas en el código y analizar qué atributo va a dónde.
Un beneficio más es que object s puede implementar interfaces / rasgos, a diferencia de los métodos estáticos.
Los objetos complementarios son el primer lugar en el que se buscan las implicaciones, después de eso, Scala busca en Predef y luego en declaraciones de "importación" explícitas en ese archivo fuente en particular.
No soy lo suficiente de un desarrollador de Java para saber si el lenguaje Java o las bibliotecas proporcionan algún mecanismo comparable.
Lea otras preguntas en las etiquetas scala