Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How is the POJO/JavaBean pattern treated in Scala?

Tags:

scala

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 meaning:

  1. Constructor that takes no parameters
  2. attributes are private, getters and setters are public
  3. getters and setters defines properties, hiding attributes

Also, does Scala have opinions (sorry, I dislike using this term) on using the old public, private, protected attribute designs that is relevant to this question?

like image 527
Jesvin Jose Avatar asked Mar 12 '12 19:03

Jesvin Jose


People also ask

What is the difference between POJO and JavaBean?

POJO can have other than private fields whereas Java beans can only have private fields. POJO may or may not have a constructor whereas Java beans should have a no-argument constructor.

How does POJO work?

POJO stands for Plain Old Java Object. It is an ordinary Java object, not bound by any special restriction other than those forced by the Java Language Specification and not requiring any classpath. POJOs are used for increasing the readability and re-usability of a program.

Can POJO have methods?

A POJO has no naming convention for our properties and methods. This class can be used by any Java program as it's not tied to any framework.

What is POJO class in spring boot?

POJO is short for Plain old java object, an application implemented in pojo way means the logic resides in POJO with little to no boilerplate code, thus it's very portable. An PoJo application can be ported from Spring to another container with little modification.


1 Answers

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)
like image 149
Tomasz Nurkiewicz Avatar answered Nov 02 '22 20:11

Tomasz Nurkiewicz