How is the POJO/JavaBean pattern treated in Scala?

Question

Just like the question. Does scala promote it same way as Java? Or has it been evolved to be more idiomatic to Scala? Or has it been made irrelevant?

POJOs and JavaBeans

Answer 1

Scala also has POJO-like idioms but they are different than JavaBeans and Scala puts emphasis on different aspects.

1. Scala has different naming conventions:

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

   This way you can always write obj.foo and obj.foo = bar even if you decide to switch from getters/setters to direct field access and vice-versa. This is called uniform access principle.

2. Due to Java interoperability, @BeanProperty annotation was introduced:

   @BeanProperty var foo: Foo = _
   

   the code above not only creates Scala-like getters/setters, but Java-like as well, so all Java frameworks work seamlessly.

3. Scala forces you to decide between variables (var) and values (val), so you find yourself much more often using immutable objects

4. I really prefer immutable objects and initialization in constructor, which has been made very easy in Scala:

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

   or even (val by default in case classes):

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

   This piece of code is brilliant in its simplicity. However, if you need to cooperate with Java frameworks, you still need no-argu constructor and setters:

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

   Note val being replaced by var.

5. Access modifiers in Scala have slightly better defaults compared to 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 and b will become private fields with public getters/setters (fields are private by default, methods are public). c and d are private variables as well. But the extra private[this] makes d be accessible directly internally in the class rather than by private getter/setter.

   Because x is used somewhere beside the constructor, Scala automatically creates private field for it as well. However no getters/setters are generated, it is accessed directly in twisted method (same as d).

UPDATE: In comments you are asking about renaming getters/setters. Here is even more complex example. Getters/setters are computing the value based on two fields at the same time:

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
    }

}

Looks complicated inside, but from the outside it looks like good old property:

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

Just like if it was:

class Foo(var fake: String)