A Better Standard for Avoiding @Getter and @Setter Overuse

Where the Problem Started

Lombok reduces a lot of repetitive Java code, but opening getters and setters for every field just because it is convenient weakens object responsibility. This post is less about style preference and more about how a domain object should protect its own state.

Among Spring Boot Lombok annotations, @Getter and @Setter are used very often.

Implementation Path

public class Person {
    private String name;
}

This defines a class called Person.

    public String getName() {
        return this.name;
    }
    public void setName(String name) {
        this.name = name;
    }

Then you create getter and setter functions like this inside the class. @Getter and @Setter make it quick to define these tedious functions.

They have several advantages, such as faster development, less boilerplate code, and easier refactoring.

@Getter(AccessLevel.NONE)

Design Takeaway

Reducing getters and setters is not about making code inconvenient. It is about making the intent of state changes visible in method names and preventing outside code from manipulating an object freely. Even a small annotation can weaken a domain boundary when applied without thought.

You can also control access levels like this.

Because of this convenience, when implementing entities, DTOs, VOs, and similar classes, it becomes a habit to add @Getter and @Setter first before even defining the class properly.

This post covers several drawbacks that come from overusing @Getter and @Setter.

Encapsulation Violation

By exposing fields through @Getter and @Setter, you damage encapsulation. Encapsulation, one of the core characteristics of OOP, protects data from the outside through information hiding. Its value drops because public functions allow the entity state to be changed without any constraints.

Unintended Conflicts

Granting direct access to entity fields can create unexpected bugs. For example, if you modify the id field of a JPA entity, the relationship with the database can become defective.

Or, if changes happen after relationships between multiple entities have already been formed, data inconsistency can occur.

API Pollution

When @Getter and @Setter are added to every field, the public API also grows dramatically. For example, if you document APIs with Swagger, core APIs can be mixed together with APIs such as getField and setField, creating confusion between what is essential to business logic and what is not.

Cases Where They Are Not Needed

There are also cases where @Getter and @Setter are not needed at all in an entity. For example, when using a DTO, there may be no need to expose public access to the data the client wants.

Lazy Loading

Some fields in JPA entities are configured with lazy loading to improve performance. If these fields are fetched with @Getter during a live Hibernate session, LazyInitializationException and similar errors can occur. In worse cases, unintended database queries can be executed.