Have you stopped thinking about using getters / setters in DTO design patterns?

When implementing a DTO design pattern in Java, you add setter / getter I wonder if I have stopped thinking.

• Quoted from DTO Wikipedia Data Transfer Objects (DTOs) are a type of design pattern used to transfer data between subsystems in application software.

It looks like this as an implementation.

class Hoge
{
    private int value;
    public int getValue(){ return value; }
    public void setValue(int value){ this.value = value; }
}

Considering the purpose, I think that logic should not be included. Then the implementation will only have getters / setters for the fields. Encapsulation isn't working at all, so it's refreshing what you want to do.

• I can understand stories such as being uncomfortable because of the unity of the whole.

So the implementation that makes the field public is simple. Convenient to complement from the IDE!

class Hoge
{
    public int value;
}

Then, as a factor to be thrust next, it is not a Java bean You may be told.

However, considering the purpose of DTO, it should not be necessary to become a bean. Why do you want to make it a bean? If you think

I can't use "BeanUtils.copyProperties"! May be said. But isn't it misunderstanding the purpose and means? I think. It should be established as a DTO.

So why would you want to use "BeanUtils.copyProperties"? I think it will be.

next time Did you stop thinking about using BeanUtils.copyProperties?

If you have any opinions or impressions, please let us know.