Do you really need encapsulation when you are not exposing anything to anyone?

Question

Please read before referring me to post like those, I'm asking about a very specific case :

Why use getters and setters/accessors?

What is the use of encapsulation when I'm able to change the property values with setter methods?

Let's take for example a JAVA JEE application, those are basically websites. Your bank website is probably a JAVA JEE application.

On those we are a generally a team of 10-15 devellopers, nobody except us uses our code, nobody imports our package and uses our objects.

The backend usually have DAOs to access the database and Value objects to transfert data to the presentation layer.

The VOs are perfect copies of the entities, example :

public class UserVo {

private String name;
private String email;
private String password;

public UserVo(String name, String email, String password) {
    this.name = name;
    this.email = email;
    this.password = password;
}

public String getName() {
    return name;
}

public void setName(String name) {
    this.name = name;
}

public String getEmail() {
    return email;
}

public void setEmail(String email) {
    this.email = email;
}

public String getPassword() {
    return password;
}

public void setPassword(String password) {
    this.password = password;
}

}

So you get an entity, you convert it to a VO for "layer separation" (which I don't see the point either because if you change an entity you change the VO then you change the code in the presentation layer that use that VO but whatever)

First of all a VO is suposed to be immutable, but on all the projects that I've worked for they are mutable.

My question is : is there an advantage here to have getters/setters ?

• There is no logic inside, some will tell you that a setter can do some validation but this is not useful because all our code is unit-tested so there is no need to validate anything in the setters.

• Since all properties have a get/set is is exactly the same as if they were public.

• When the implementation changes the getter/setter are changed too and all the code that uses the old getter/setter is refactored/modified.

• I often get told about data hiding, that the user won't be able to access a private property : what? the user is browsing a website.

So, why is everybody so attached to those getter/setters? if I uses public properties instead of those getter / setters I will be ridiculed, everyone saying things like "don't you know about encapsulation", "you should NEVER have public fields"

My take on it is that it's useless, but everybody does it because it is how it has always been done and nobody ever ask questions about it.

Am I wrong?

Thanks.

Answer 1

Am I wrong? In the example you've shown I would state that no, you're not wrong. This has to do with the distinction of objects vs data structures and it seems that UserVo is a data structure thus rendering those getters and setters totally useless.

Objects hide their data behind abstractions and expose functions that operate on that data (including getters and setters). Data structures expose their data and have no meaningful functions. (Clean Code, Robert Martin)

Now in Java everything is an actual object and the language does not supports data structures. But that does not force me to create an object to act like a data structure.

I mean why on earth would I prefer this

public class Point {
 private double x;
 private double y;

 public double getX(){
  return x;
 }

 public double getY(){
  return y;
 }

 public void setX(double x){
  this.x = x;
 }

 public void setY(double y){
  this.y = y;
 }
}

over this?

public class Point {
 public double x;
 public double y;
}

Answer 2

Java was designed without any idea of implementing a universal access principle (where the caller doesn’t distinguish whether they are using a field or a method, they’re called the same way). That means, rather than introduce a getter only once you need it, you tend to put it in up front because it will be a pain to introduce it later.

So people naturally default to using getters/setters. Also naturally, the reasons for doing this are fear-based and nebulous-sounding because it is all about dealing with an unknowable future.

One practical consideration is most pojos get used with frameworks or libraries that expect getters and setters. In those cases the choice is out of your hands.

In many cases validations and conversions are better off being done outside of the pojos (see validators in spring mvc for instance, or Jpa converters), but in other cases we need getters/setters for validating/converting (or are afraid we will eventually).

TLDR: the language was designed in a way that penalized putting in getters/setters only when needed, so you got a culture of people insisting on them upfront in all cases.

There are languages where immutability is widespread, like clojure. They get by fine without encapsulation. Immutability is still unfamiliar to a lot of java programmers and the best practices assume mutable state. To me the posted Value Object would be better off being immutable because when otherwise when reading the code I can't discount the possibility something will modify it after it is sent.

Answer 3

So, why is everybody so attached to those getter/setters? if I uses public properties instead of those getter / setters I will be ridiculed, everyone saying things like "don't you know about encapsulation", "you should NEVER have public fields"

My take on it is that it's useless, but everybody does it because it is how it has always been done and nobody ever ask questions about it.

Because it is a religion – meaning "Strictness of fidelity in conforming to any practice, as if it were an enjoined rule of conduct." – Webster