0

I am working on some practice questions for the OCP 8.

One question featured a class with private fields and private getter methods. The correct answer was that this code violates encapsulation because the getter methods should have been public.

public class A {
    private String a;
    private String getA() { return a; }
}

However, another question featured a class with private fields and no getter methods at all. The correct answer was that this code follows encapsulation principles. 

public class A {
    private String a;
}

Assuming all data fields are private, shouldn't the order of most encapsulated to least be no getter methods, private getter methods and public getter methods?

I know my question might sound opinion-based, but the exam is not.

Andrew Tobilko
  • 48,120
  • 14
  • 91
  • 142
K Man
  • 602
  • 2
  • 9
  • 21
  • 2
    _"...the exam is not [opinion-based]."_: ideally true, but likely far more untrue than the examiners would care to admit (;->) – Kevin Anderson Oct 19 '19 at 14:33
  • 1
    Throughout the mentioned book, they write (*In Java, it is commonly implemented with **private instance members** that have **public methods** to retrieve or modify the data, commonly referred to as getters and setters, respectively.* and *In Java, it is often implemented with JavaBeans, using **the private access modifier on instance variables** and **public getter and setter methods**.*) pushing this commonly accepted and used rule. They expect you to follow this idea within the scope of the exam. That said, both examples look correct to me and don't violate encapsulation. – Andrew Tobilko Oct 19 '19 at 14:57
  • 1
    Related: https://stackoverflow.com/questions/8983709/why-would-you-declare-getters-and-setters-method-private – Andrew Tobilko Oct 19 '19 at 14:58

2 Answers2

6

Private getter methods do not violate encapsulation. That is just nonsense.

I am not expressing an opinion here. It is a fact that a Java private method can only be called within the class that declares it. That is inside the boundary of encapsulation.

Either you have misread the OCP sample question and answer, or they have made a mistake.

Now it could be that what they were trying to ask was whether the example class was an example of good encapsulation or more generally of good OO design.

UPDATE

Seeing the example code, it is hard to say one way or another. It is too unrealistic to make a judgement. (The code is literally useless, but unless we know what its intended use was, we can't really call this bad design.)

Another answer seems to be arguing that private getters are useless. I disagree. Especially since a getter may do other things apart from simply returning a value. Consider this:

private synchronized void setBalance(int newBalance) {
    this.balance = newBalance;
}

private synchronized int getBalance() {
    return this.balance;
}

This ensures that the caller will see the current value of the balance field even if it was just updated by another thread. Sure we can do it other ways, but this way is good separation of responsibilities.

And there other that a private getter could legitimately do.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • [Another answer of yours](https://stackoverflow.com/a/8983883/4922375) doesn't think "that is just nonsense". – Andrew Tobilko Oct 19 '19 at 15:01
  • That question is not about whether private getters violate encapsulation. It is about whether private getters and setters are useful. (Or perhaps you misunderstood what I am saying here.) – Stephen C Oct 20 '19 at 01:15
0

Because, if you make a getter as private, then there is no way to access that data member in another class. We use a getter to access the private data member in another class. So if you are making getter as private, then what is the use of that getter.

Shekhar
  • 64
  • 7
  • 1
    why can't the private getter be used iniside the class itself? e.g. nested classes. And "there is no way to access that data member in another class" also if not having a getter - part 2 of question. – user85421 Oct 19 '19 at 15:01