I’m a huge believer in consistency, and hence conventions.
However, I’m currently developing a framework in Java where these conventions (specifically the get
The get-less schema is used in a language like scala (and other languages), with the Uniform Access Principle:
Scala keeps field and method names in the same namespace, which means we can’t name the field count if a method is named count. Many languages, like Java, don’t have this restriction, because they keep field and method names in separate namespaces.
Since Java is not meant to offer UAP for "properties", it is best to refer to those properties with the get/set conventions.
UAP means:
Foo.bar
and Foo.bar()
are the same and refer to reading property, or to a read method for the property.Foo.bar = 5
and Foo.bar(5)
are the same and refer to setting the property, or to a write method for the property.In Java, you cannot achieve UAP because Foo.bar
and Foo.bar()
are in two different namespaces.
That means to access the read method, you will have to call Foo.bar()
, which is no different than calling any other method.
So this get-set convention can help to differentiate that call from the others (not related to properties), since "All services (here "just reading/setting a value, or computing it") offered by a module cannot be available through a uniform notation".
It is not mandatory, but is a way to recognize a service related to get/set or compute a property value, from the other services.
If UAP were available in Java, that convention would not be needed at all.
Note: the size()
instead of getSize()
is probably a legacy bad naming preserved for the sake of Java's mantra is 'Backwardly compatible: always'.