implicitly - Explicación de objetos singleton en Scala

scala sintaxis

Question

Obtengo la codificación porque básicamente se proporciona un "objeto SomeClass" y una "clase SomeClass" y la clase complementaria es la declaración de clase y el objeto es un singleton . De los cuales no puedes crear una instancia. Entonces ... mi pregunta es principalmente el propósito de un objeto singleton en esta instancia particular.

¿Básicamente es solo una manera de proporcionar métodos de clase en Scala? Me gusta + métodos basados ​​en Objective-C ?

Estoy leyendo el libro de Programación en Scala y el Capítulo 4 acaba de hablar sobre objetos singleton, pero no entra en muchos detalles sobre por qué esto es importante.

Me doy cuenta de que puedo estar adelantado aquí y que podría explicarse con mayor detalle más adelante. Si es así, házmelo saber. Este libro es razonablemente bueno hasta ahora, pero tiene mucho "en Java, haz esto", pero tengo tan poca experiencia en Java que echo de menos un poco de los puntos que temo. No quiero que esta sea una de esas situaciones.

No recuerdo haber leído en ninguna parte del sitio web de Programación en Scala que Java era un requisito previo para leer este libro ...

Answer 1

Adicional a las respuestas dadas (y yendo en la misma dirección general que jilen), los object desempeñan un papel importante en el mecanismo implicit de Scala, por ejemplo, permitiendo el comportamiento tipo-clase (como lo conoce Haskell):

trait Monoid[T] {
def zero:T
def sum(t1:T, t2:T):T
}
def fold[T](ts:T*)(implicit m:Monoid[T]) = ts.foldLeft(m.zero)(m.sum(_,_))

Ahora tenemos una función de fold . que "colapsa" un número de T s juntas, siempre que haya un Monoid apropiado (cosas que tienen un elemento neutral, y pueden "agregarse" de alguna manera juntas) para T Para usar esto, solo necesitamos una instancia de un Monoid para algún tipo T , el trabajo perfecto para un object :

implicit object StringMonoid extends Monoid[String] {
def zero = ""
def sum(s1:String, s2:String) = s1 + s2
}

Ahora esto funciona:

println(fold("a","bc","def")) //--> abcdef

Así que los object son muy útiles por derecho propio.

¡Pero espera, hay más! Los objetos acompañantes también pueden servir como un tipo de "configuración predeterminada" al extender su clase acompañante:

trait Config {
def databaseName:String
def userName:String
def password:String
}
object Config extends Config {
def databaseName = "testDB"
def userName = "scott"
def password = "tiger"
}

Así que, por un lado, tiene el atributo Config , que el usuario puede implementar de la forma que quiera, pero por otro lado hay una Config objeto preparada cuando desea ir a la configuración predeterminada.

Answer 2

En muchos casos, necesitamos un singleton para representar un objeto único en nuestro sistema de software. Piensa en el sistema solar. Podemos tener las siguientes clases

class Planet
object Earth extends Planet
object Sun extends Planet

objeto es una forma simple de crear singleton, por supuesto se usa generalmente para crear un método de nivel de clase, como método estático en java

Answer 3

Sí, básicamente es una forma de proporcionar métodos de clase cuando se usa como un objeto complementario.

Answer 4

Sí, los singletons complementarios proporcionan un equivalente a los métodos estáticos de Java (y C ++, c # s, etc.).

(de hecho, los métodos de objetos complementarios se exponen a través de "reenviadores estáticos" por el bien de la interoperabilidad de Java)

Sin embargo, los singleton van mucho más allá de esto.

• Un singleton puede heredar métodos de otras clases / características, lo que no se puede hacer con estática.
• Un singleton se puede pasar como un parámetro (quizás a través de una interfaz heredada)
• Un singleton puede existir dentro del alcance de una clase o método circundante, así como Java puede tener clases internas
• También vale la pena señalar que un singleton no tiene que ser un acompañante, es perfectamente válido para definir un singleton sin definir también una clase complementaria.

Lo que ayuda a Scala a ser un lenguaje mucho más orientado a objetos que Java (los métodos estáticos no pertenecen a un objeto ). Irónico, dado que se discute en gran medida en términos de sus credenciales funcionales.