2

I had been asked the following question in an interview and i am curious to know the answer.

There are two classes as following,

public class EmployeeA{
    public int empId;
}
public class EmployeeB{
    private int empId;

    public void setEmpId(int empId){this.empId = empId;}
    public int getEmpId(){return empId;}
}

There are two classes where one class has a public instance field and other have a private field with getters and setters. In this case, which is better implementation and why? [I have learned that making instance variable private is the better idea. But in both cases i can modify the value of empId attribute. ]

JPS
  • 2,730
  • 5
  • 32
  • 54
  • Keeping properties `private` and providing `getter` and `setter` methods on "as needed" basis contributes to better encapsulation and less coupling. – PM 77-1 Nov 04 '14 at 03:49
  • 2
    In layman terms, OOP developer should be a *control freak*, always trying to retain as much control over *his* stuff as practical. – PM 77-1 Nov 04 '14 at 03:51

3 Answers3

3

The one-word answer they're probably looking for is "encapsulation".

By encapsulating the private field value, you have the opportunity to change the logic on how the value is set/retrieved in the future. Say, for example, you want to validate on set and filter on retrieval (get). By encapsulating the value, your creating an API which allows for better maintenance moving forward.

Steve Siebert
  • 1,874
  • 12
  • 18
  • This was the exact statement that i had given during interview. But he introduced a constraint, 'there will not be any change needed during get/set action'. So i am curious to know if there is any concept behind this except Encapsulation or modification inside getters and setters. – JPS Nov 04 '14 at 09:49
  • Well, like every other OOP concept (polymorphism, inheritance, etc), they are all interleaved. One scenario could be that the class your building now will be inherited. Again, focused on the fact that creating a public method (getter/setter/or any other method) is the objects API, your saying that subclasses will comply with your API. So, this class may set a local variable, a subclass may do something more significant for that subclass (polymorphism). – Steve Siebert Nov 04 '14 at 09:58
  • Yet another, arguably non OOP reason, is that LOTS of java frameworks work off the "POJO" pseudo-specification. Many of these frameworks (JPA, JAX-B, etc) rely (on some part) of having a getter/setter method to identify POJO "properties". – Steve Siebert Nov 04 '14 at 10:00
  • Finally (sorry for multi-comments, limited to comment length) another option could be that it makes your field values accessible for reflection, especially when the SecurityManager is being used and private fields are actually protected =). If your code, or code you're using, is using reflection, it's often easier to leverage a "POJO framework" and/or use the getter/setter method signatures than it is to have to get your policy file just right =) – Steve Siebert Nov 04 '14 at 10:02
1

Maybe a bit off-topic, although people usually talk about "encapsulation" when talking about "getter/setter", "getter/setters" are actually still far from proper encapsulation.

This famous "why getter and setter methods are evil" is something worth to read. When we say getters and setters are evil, it doesn't mean that we should expose variable directly. It is about further hiding internal data by providing meaningful behavior in class, instead of providing accessors for properties. Although there are a lot of cases we still need accessors, this is something that worth giving attention when you are designing.

Going back to your question, if it is me, I will answer: providing getters and setters provides a minimal level of encapsulation and allow us to do extra work or derives data when we are setting and getting properties. However, for a proper encapsulation, I would rather design the Employee class to provide proper behaviors, instead of simply acting as a value object which only provides bunch of getters/setters.

Adrian Shum
  • 38,812
  • 10
  • 83
  • 131
0

The accesssor (getter) and mutator (setter) are JavaBean requirement but not all classes in Java must follow this design pattern. Why not creating this class as immutable by having a constructor that take the id (or even better, a static factory). You can then provide an accessor for the the id. That is generally not a good idea to be able to change the id of an object, if the id is used in a Map as the key and you change it, good luck to retrieve you object... Make the class immutable solve this kind of problem.

PLariviere
  • 1