Is there any use to using getters / seters inside a class for custom fields?

Question

Usually in my own projects I use getters and setters for any access to the fields, and I made sure to do the same in my work. Some time ago, the technical manager of our project asked me why I was doing this and why it was better than just using the fields themselves (with the ability to declare them protected if they need to access subclasses). I could not answer a clear answer.

So, are there any reasons to use getters and setters inside the class for the class’s own fields or is it better to use the fields directly?

Answer 1

The most obvious answer is the side effects:

int getCost() { if (cost == null) { calculateCost(); } return cost; } 

If you need value, use getCost() . If you want to know if a value has been calculated, use cost .

Answer 2

If there is any business logic between these values ​​(or there is potential for such logic), then there is an advantage to using getters and setters even for internal calls.

For example, your setter may perform a check on its inputs and throw an exception rather than storing an invalid value. Having all your code used by this installer, and not just setting the values ​​directly, means that the error was caught at the time of its creation, and not after a while when this value is used. A similar case for a getter is when there is a logical default, which should be used in the case of null. Using a getter, you can safely write local methods without requiring continuous null checks or default parameters.

However, if there is no business logic in these methods and no side effects caused by them, then this is basically a stylistic thing. Essentially, a class must be internally consistent, and as long as it remains that way, it mainly prefers personal or professional preferences, regardless of whether you access variables directly or using packaging methods.

Answer 3

You want to declare them public recipients and setters and private fields. This means that external classes (not subclasses) that want to change the variables do all this through setters and get them through getters. The advantage of this is that if you want to control how or what condition they receive or set, or want to add information or even print a debug version, this means that you only need to put it in getters and setters.

There's a really good explanation of the benefits on stackoverflow actually:

In Java, the difference between standard, public, secure, and private

Of course, only create methods when they are really needed, and in the same way, only public when necessary for external classes.

Hope this helps protect!

Answer 4

This is part of the general question of why you use getters and setters. Many developers use them, albeit in practical terms. Personally, I only put getters / setters if I need to.

I would advise you to do what is clearer / easier for you.

In general, if I can easily add getter / setter later, if I need it, I will not add it. If it will be difficult to add later (or you have immediate use for them), I would include them.

Answer 5

Some of us are web developers, so we resort to creating JavaBeans , and JavaBeans has its own specification . The specification clearly states:

• The class must have an open default constructor (no arguments).
• Class properties should be accessible using get, set, is (used for boolean properties instead of get) and other methods.
• The class must be serializable.

The reason is that JavaBeans were developed for Reusability , where JavaBeans could travel on any Java technology (e.g. servlets, JSP, RMI, web services, etc.).

That my 2price is on why we have getters / setters. I mainly create JavaBeans.

Answer 6

Some people think that they should always encapsulate all fields using seters / getters. Others believe that this practice should not be used at all.

If your class does not have any logic for fields and is simply used as the owner, you can skip using methods and just declare your fields public. This concept is also called a data transfer object (or Messenger.) But, as a rule, you should use the final attribute for such fields to make your class immutable:

 public class TwoTuple<A,B> { public final A first; public final B second; public TwoTuple(A a, B b) { first = a; second = b; } } 

However, you should / or strongly recommended using setters / getters:

• Web applications sometimes have requirements for using setters / getters. See POJO / JavaBean Objects.
• if your class will be used in a parallel environment. See Java Concurrency in Practice, Section 3.2: “Whether another thread really does something with the published link doesn't really matter, because the risk of abuse is still present. [7] Once the object runs away, you must assume that another class or thread may, maliciously or carelessly, abuse It is a compelling reason to use encapsulation: it makes it practical to analyze programs for correctness and it’s harder to break constructive constraints by accident "
• if you want to add additional logic when setting / getting values, you should use seters / getters. Just read about encapsulation and its benefits.

My own opinion always declares the fields a “private finale”, and only after that, if necessary, change these properties.