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:
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?
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.
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.
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.
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.
Scala also has POJO-like idioms but they are different than JavaBeans and Scala puts emphasis on different aspects.
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.
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.
Scala forces you to decide between variables (var
) and values (val
), so you find yourself much more often using immutable objects
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
.
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)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With