0

Sometimes I encounter with the getters/setters in Spring code.

Is there any alternate to this technique?

I'm new to this technique.

gustafc
  • 28,465
  • 7
  • 73
  • 99
  • 1
    That is not Spring specific. If you want to use encapsulation in Java, you will need some sort of getter/setter (if not using reflection, bad idea) – PeterMmm Jan 18 '23 at 08:22
  • If you don't want to write them everytime you can always use "@getter" and "@setter" from lombok. Be aware that however this seems correct, it sometimes is not what you expect. – DJ Freeman Jan 18 '23 at 08:24
  • "Is there any alternate to this technique" -> we can't answer you if we don't know what you are trying to do, if you could add a specific example with code the question would be clearer – Kaddath Jan 18 '23 at 08:28

3 Answers3

0

I assume you know the motivation for getters and setters in general; if not, see Why use getters and setters/accessors?

As for Spring, accessors aren't strictly needed in most cases (but considering the huge amount of libraries in Spring, in some cases you might need them). They're often believed to be needed for Spring to inject dependencies, but in most cases Spring can inject into constructors or public fields.

There are valid reasons for using accessors instead of public fields for mutable objects, but that's a matter of taste and style. IDEs like IntelliJ can automatically add accessors for unencapsulated fields (or de-encapsulate private fields with accessors) so unless you're writing a 3rd party library others will use as a dependency, it's not really that important what you choose.

gustafc
  • 28,465
  • 7
  • 73
  • 99
0

Spring doesn't need getters and setters.

Most injection should be done through constructors. Only optional dependencies should be injected through setters. If you have a problem with setters you may always inject into fields directly, although I would prefer the setters, because you can use those to setup beans in tests without Spring and without reflection.

I don't know of a place in Spring where getters are required.

Of course, Spring is all about integrating pieces and many of those pieces might require getters and or setters, since it is a common pattern in Java (although a rather stupid one). For these cases one would have to look at the individual libraries.

Jens Schauder
  • 77,657
  • 34
  • 181
  • 348
0

Two reasons i know:

1. we have a entity like this:

public class Person {
    public int age = 50;
}

then we use that for 100+ other service like this:

public class S1{
    displayAge(Person p) {
        System.out.println(p.age)
    }
}
public class S2{
    displayAge(Person p) {
        System.out.println(p.age)
    }
}
.
.
.
public class SN{
    displayAge(Person p) {
        System.out.println(p.age)
    }
}

Now the requirements have changed, if the age is greater than 50 years old, it should display "old people", what would you do? you must change all service. but if use getter, would be like this:

public class Person {
    public int age = 50;
    public String getAge() {
        return age > 50 ? "old people" : "young people";
    }
}

public class S1{
    displayAge(Person p) {
        System.out.println(p.getAge())
    }
}

public class S2{
    displayAge(Person p) {
        System.out.println(p.getAge())
    }
}
.
.
.
public class SN{
    displayAge(Person p) {
        System.out.println(p.getAge())
    }
}

You don't need to hack to change all services, just change the getter or setter. Of course, this is a simple example, in practice, you need to decide for yourself.

2. Many frameworks, when using, will call the getter or setter method of the corresponding property through reflection according to the property of the class. If you use this kind of framework, you need to provide the corresponding getter and setter method, such as some frameworks for operating databases.

At last,If you just use an object to transfer data yourself, you can actually do without getters and setters at all.

In fact, the rules and regulations during development are for better collaboration with others, or to make the program more robust. If you can control it well, you don't have to be dogmatic.