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.

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.

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.

Recommended Posts

Have you stopped thinking about using getters / setters in DTO design patterns?
Have you stopped thinking about using BeanUtils.copyProperties?
Why you need setters / getters in the first place
Have you ever thought about the definition of "bad design"?
Read design patterns in Ruby