Rachel Rosemond

Take a real‑world example. I often think there are things about me which are “public” which anybody is allowed to access, for example looking at my face (they don't usually do that twice).

Don't be hard on yourself

When you go through Effective Java next time, look for the chapter about defensive copies. String is immutable, so you cannot mess up the innards of the object by returning it.

I favor immutable classes and well aware of now to make immutable copies Effective Java is indeed a good resource.

My problem lies with the many definitions about what breaks in encapsulation. Some say simply providing getters breaks encapsulation, while some say as long as it's not for every field, it's okay.

In Effective Java, it says to provide access to all the individual elements return by the toString()(Not actual quote, but all those lines).

Suppose following that guideline from Effective Java, I have to provide getters for all the fields(My Book example), what then?

My whole problem is, I stand behind the definition that, even if you provide getters for all the fields because that's what's returned in the toString(), as long as you're not implemeting a behaviour or calculation outside the class by calling getters, then it's fine. BUT, there is that voice that always says, IT WRONG. This is where I get discourged, and don't really know what to do. I don't have years of experience, or a CS degree, and I'm in no position to refute any statement about encapsulation. Why can't there be a solid definition about what breaks encapsulation and what doesn't?  

While browsing Software Enginnering Stack Exchange, I've come across posts that suggest the use of getters should be avoided. The suggested alternative, to me anyways, seems to violate the SRP, by allowing your class to be aware of UI/display code. Here an example of the posts I'm talking about: Encapsulation and Displaying Information

or the accepted answer to this question: Encapsulation and Getters

The accepted answer to this question is what I have in mind and agree with: Avoid getters and setters, displaying user informations

Once your not using the getters to gather information and do a calculation or implement a behavior that should be inside the class, using a getter is fine. As eloquently stated by Junilu Lacar in this post: Encapsulation and GUI

Yes, the idea I explain in the other thread is about getters breaking encapsulation when an external calculation that uses raw information you obtain via the getter is made. This moves logic that should be inside the object elsewhere outside of it. Displaying information about an object obtained via a getter is not the same. You are not performing calculations with the information and externalizing logic that should be in the object being examined. In this way, the use of getters is fine and it doesn't break encapsulation.

I guess breaking encapsulation only happens when the information you take from the object also involves taking away the responsibility of interpreting that information from said object.

But there are posts on other sites, like the ones above that seem to refute even using getters for display. Instead they seem to suggest ideas like returning an array or Map collection of the data. This seems unnecessary and a lot of work for the simple task of displaying.

Another thing is, suppose you wanted to use a design pattern, for example, the Visitor pattern. This pattern breaks the guideline that you shouldn't use the getters to gather data and preform a calculation that should be done inside the class. Quote from Dzone:

What the Visitor pattern actually does is create an external class that uses data in the other classes. If you need to perform operations across a dispate set of objects, Visitor might be the pattern for you.

Even in Effective Java states:

Provide programmatic access to all the information contained in the value returned by the toString()

I often see the following statements, but I don't know to threat them.

Avoid Getters, they're evil. If your providing a getter for every field, you're doing something wrong and you need to rethink your design.

Another issue is I often here the phrase,  Tell, don't ask. Fine, but what about objects where that's impossible? For example, suppose I have a Book object, my object will obviously have a title and a list containing all the authors.  If I wanted to display this in a UI, I would implement and call the getters. I can't tell a Book, "Hey, book, what's your title?" A person reads title off of the Book. I could have a method called readTitle(), but that's just a getter without really calling it a getter. A person, can jump to the end and determine the number of pages of the book. Now, if I've read a few of the pages and wanted to know how many I have left, then I would write an internal method called numberofpagesleft(int pagesread) and do my calculation and return the result.

 

Questions:

1. How should I threat what theses developers are saying? do I take what they say as rules set in stone? Or threat them as guidelines? be aware of them, try to use them, but if after you thought if over, and you have to go against one of these guidelines, do it, if and only if, it makes sense?

2. How do I silence the voice that bothers me everytime I write a getter for display that says, "You're doing something wrong" but the thing is what should I do? The alternative violates SRP and causes more problems. What's even more interesting is, those same developers that say Getters are evil and should be avoided, they have to sometimes implement them when using Compartor, and they justify it by twisting there defination about getters. Like so:Does the use of Comparator interface breaks encapsulation in Java?

Taking my Book example and display for UI, I would provide a getter of all three fields(Title, List of Authors, and Number of Pages), because that's what represents my Book object and is returned in the toString(). Now how do I come to terms with those developers that believe I'm breaking encapsulation by providing getters for every field, without violating the SRP?