Is it always better to use access methods, even when accessing a local state?

Question

Consider the following class:

public class Person { private Integer age; // Standard Accessors public Integer getAge() { return age; } public void setAge(Integer age) { this.age = age; } public String getAgeAsTextString() { if (this.age == 20) { return "Twenty"; } return "Unknown"; } } 

I have only 1 Integer and 2 accessors. If I want to create a utility method that returns the state of objects as a String, is it best to use a class variable like this.age , or should I use getAge() ?

Is there any best practice or is it reduced to discretion of developers?

Answer 1

It depends. For small quick classes, when accessors don't do anything, I would say use the field directly. For larger classes, where accessories and setters can have side effects, I would say that they use accessors.

On the Android platform, the Android documentation seems to agree. In some cases, they even recommend recommending packet-level protection. See the “Avoid Internal Getters / Setters” and “Use Package Area with Internal Classes” sections at http://developer.android.com/guide/practices/design/performance.html .

It all depends on the environment, the size of the code, and if there are agreed "standards" for the purpose of serving the code. Just know that there is a slight performance difference, but ultimately it depends on the developer / team.

Answer 2

I would say that it depends on the developer.

I prefer using the getter method a bit. And if you have a class hierarchy, it is useful to open the internal state through protected getters.

Answer 3

This is good practice because you can never be sure how you might need age to change later. It may take some kind of verification or something else, and it’s easier to change it in one way than wherever the field is used (and it’s much easier to miss one place where it is used, and therefore, track the potential error with some difficulty).

Answer 4

If your class is final, I would get access to the fields directly. Trust your refactoring capabilities. If you want to change it later, you can always do it.

Answer 5

I like to use getters and setters even for simple classes, because it creates Hooks in your code, which makes it easy to extend. So, if you want to create an audit record every time a user changes the property of a particular object, this is easy to do. Then, when I get to the end of my project, I will take a moment and remove the getters and setters that I have not used. I believe this is effective because most IDEs will generate accessors for you, so you have little time to spend ...

I see a people post, "If you want to change it later, you can always do it." . This is not always trivial in large projects when you directly access your object properties throughout your code.

Answer 6

For your love of God, do not mix your code with oxymoronic "encapsulation." A class is your module. Make your class simple.

Also, create the interface of your class in terms of behavior, not data. Drop the get and set methods.

Answer 7

Often people go with this.age to a simple class, but consider the benefits of using accessories when you already have one. If you want to enter one day, say, in a journal when someone gets their age, you will have to put it in every place that you call this.age. Or instead, you can just put it in an accessor. The style of the code is not always fixed, but there is usually a good reason if you are looking for it.

Answer 8

One thing to remember. When using something like Hibernate, accessories are usually required! He bit this one several times. Hibernate uses bytecode generation for lazy initialization. if you access the member variable directly, you will skip lazy loading and get null values. So, my personal practice is to use an accessory. Like all best practices, of course, there are times to ignore it, but there you go.

Answer 9

A few reasons accessors may be the best option:

• You use a fake framework to test your code and want BOTH to change the value returned from getter and claim that it was called.
• You want to open most (if not all) of your public classes as interfaces (for example, you want to be able to create dynamic proxies, etc.). This may include access disclosure in the interface (the caller does not need to know it just to get the local property).
• You are developing a library for public consumption, and “simple refactoring” is not suitable, because it can (will) cause compile-time errors in the end-user application. Accessors can be deprecated properly without affecting the behavior of users of the earlier library.
• You want to reserve the right to change the behavior of the access device at a later point or in a derived class without deleting it completely (see the previous point).
• Many dependency injection schemes expect the bean to conform to the JavaBeans specification and therefore have accessors for all properties.

Answer 10

IMHO: I follow the principle of "You-Aint-Gonna-Need-It" in keeping things simple. Many developers are worried that one day you may need a getter or setter, when in fact it will never happen.

You should do what you think is the clearest, especially to those who should support your code.

I would suggest that using int if you need a null value or an object is good practice. If you want the value to be truly empty, you should check it.

i.e. or

 int age = 10; if (this.age == 20) // cannot be null. 

OR

 Integer age = 10; if (this.age != null && this.age == 20) // age can be null 

Note

 Integer age; if (this.age == 20) // throws an NPE. 

Answer 11

While accessors add lines of code to your classes, they do add value when refactoring code. Do you need to notify another class that the property has changed? Bam! have an event and activate it in the access code.

To simply make a member variable available, you will either have to create an accessory when you need to create an event, or remember to add logic to notify the object each time an object outside your class changes a member variable.

I think that accessors are great for their flexibility regarding complexity. In addition, some frameworks, such as sleep mode, require them. In addition, languages ​​such as .net have code structures such as attributes that cannot be applied to member variables (aka WCF DataMember).

hope this helps!