2012-03-12 16 views
13

Al igual que la pregunta. ¿Scala lo promociona de la misma manera que Java? ¿O ha evolucionado para ser más idiomático para Scala? ¿O ha sido hecho irrelevante?¿Cómo se trata el patrón POJO/JavaBean en Scala?

POJOs y JavaBeans significado:

  1. constructor que no toma ningún parámetro
  2. atributos son privados, captadores y definidores son públicos
  3. captadores y definidores define propiedades, atributos escondite

También, tiene Scala opiniones (lo siento, no me gusta usar este término) en el uso de la anterior public, private, protected ¿Qué diseños de atributos son relevantes para esta pregunta?

Respuesta

33

Scala también tiene modismos tipo POJO pero son diferentes a JavaBeans y Scala pone énfasis en diferentes aspectos.

  1. Scala tiene diferentes convenciones de nomenclatura:

    def foo: Foo  //Foo getFoo() in Java 
    def foo_=(foo: Foo) //void setFoo(Foo foo) in Java 
    

    De esta manera siempre se puede escribir obj.foo y obj.foo = bar incluso si decide cambiar de getters/setters de acceso directa de campo y viceversa. Esto se llama principio de acceso uniforme .

  2. Debido a la interoperabilidad de Java, se introdujo @BeanProperty anotación:

    @BeanProperty var foo: Foo = _ 
    

    el código anterior no sólo crea Scala-como getters/setters, pero similar a Java, así que todos los marcos de Java funcionan a la perfección.

  3. Scala le obliga a decidir entre variables (var) y valores (val), por lo que se encuentra mucho más a menudo el uso de objetos inmutables

  4. realmente prefiero objetos inmutables e inicialización en el constructor, que se ha hecho muy fácil en Scala:

    class Foo(val age: Int, val name: String) 
    

    o incluso (val por defecto en case clases):

    case class Foo(age: Int, name: String) 
    

    Este pedazo de código es brillante en su simplicidad. Sin embargo, si tiene que cooperar con los marcos de Java, sigue siendo necesario ningún argu-constructor y definidores:

    public class Foo(var age: Int, var name: String) { 
    
        def this() { 
         this(0, "") 
        } 
    
    } 
    

    Nota val de ser reemplazado por var.

  5. Los modificadores de acceso en Scala tienen un poco mejor en comparación con los valores predeterminados de Java:

    class Foo(var a: Int, x: Int) { 
    
        var b: Int = _ 
    
        private var c: Int = _ 
    
        private[this] var d: Int = _ 
    
        def twisted = a + b + c + d + x 
    
    } 
    

    variables a y se convertirá en bprivate campos con public getters/setters (campos son privados por defecto, los métodos son públicos). c y d son variables privadas también. Pero el extra private[this] hace que d sea accesible directamente internamente en la clase en lugar de ser privado getter/setter.

    Dado que x se usa en algún lugar junto al constructor, Scala también crea automáticamente un campo privado para él. Sin embargo, no se generan getters/setters, se accede directamente al método twisted (igual que d).

ACTUALIZACIÓN: En los comentarios se pregunta sobre el cambio de nombre getters/setters. Aquí hay un ejemplo aún más complejo. Getters/setters está calculando el valor basado en dos campos al mismo tiempo:

class Foo { 

    private[this] var first: Char = _ 
    private[this] var rest: String = _ 

    def fake = first + rest 

    def fake_=(s: String) { 
     first = s.head 
     rest = s.tail 
    } 

} 

se ve muy complicado dentro, pero desde fuera se ve como el bueno de la propiedad:

val foo = new Foo() 
foo.fake = "ABC" 
println(foo.fake) 

Al igual que si fuera :

class Foo(var fake: String) 
+4

¿Y lo escribió todo en 8 minutos? ¡Es genial! : D – aitchnyu

+0

¿Cuál es el código cuando se desea 'aProperty' sino que se basa en un atributo' laCadena: string'? – aitchnyu

+0

@aitchnyu: Sigo editando ;-). También trabajo mucho con la integración de Scala-Java. –

Cuestiones relacionadas