3 ms·

Apparently your field was used both for some internal shenanigans as well as a public field through the get/set indirection. Then you changed the field but kep

Apparently your field was used both for some internal shenanigans as well as a public field through the get/set indirection. Then you changed the field but kept the old public behavior. I wonder whether (1) that dual purpose internal/public role was wise to be begin with, and (2) whether that change of the internal logic of the getter might have just papered over a more significant change. It might be good if a change just breaks client code. The client expects just to get/set something: they might not expect that some update migth add arbitrary logging or internal logic (like setting this value will also set another value, but we won’t tell you). Most of the get/set stuff that I see are for value objects with either no or little business logic. Simple value objects _should_ just expose their implementation.

shagie 5y ago
The backing implementation of what supplies the DTO shouldn't be an issue for the client / other part of the application if the contract that the DTO provides remains the same. If that contract is the underlying field implementation, then that means that those fields are frozen and cannot change. If that contract is instead methods, the underlying field types can change (for example from a Date to a LocalDateTime) while the method contracts remain the same and new method contracts are added to expose more functionality for other clients / application modules. In particular, this was code written in the Java 1.7 days and it was Date (and all the mess with java.util.Date and java.sql.Date) while in 1.8 java.time was provided which allowed the underlying implementation of the object to cleaned up without changing the contract of the methods (things wanting a Date still get a Date). Yes, changing from a Date to a Calendar (because of the aforementioned java.sql.Date mess) to a LocalDateTime were significant changes -- but the clients didn't notice because the methods they were using remained consistent. The deeper you expose the client contract into the guts of the object, the more difficult it is to change when a change is needed. Now, if you're just passing DTOs around between classes within a single package or local to one library that don't leak - feel free to do whatever is needed. I suspect that records will solve a lot of the boilerplate DTO code, though passing a record outside of a library boundary gives me a bit of unease because it means that changes to the record will be breaking changes to the clients.

shagie 5y ago

The backing implementation of what supplies the DTO shouldn't be an issue for the client / other part of the application if the contract that the DTO provides remains the same. If that contract is the underlying field implementation, then that means that those fields are frozen and cannot change. If that contract is instead methods, the underlying field types can change (for example from a Date to a LocalDateTime) while the method contracts remain the same and new method contracts are added to expose more functionality for other clients / application modules. In particular, this was code written in the Java 1.7 days and it was Date (and all the mess with java.util.Date and java.sql.Date) while in 1.8 java.time was provided which allowed the underlying implementation of the object to cleaned up without changing the contract of the methods (things wanting a Date still get a Date). Yes, changing from a Date to a Calendar (because of the aforementioned java.sql.Date mess) to a LocalDateTime were significant changes -- but the clients didn't notice because the methods they were using remained consistent. The deeper you expose the client contract into the guts of the object, the more difficult it is to change when a change is needed. Now, if you're just passing DTOs around between classes within a single package or local to one library that don't leak - feel free to do whatever is needed. I suspect that records will solve a lot of the boilerplate DTO code, though passing a record outside of a library boundary gives me a bit of unease because it means that changes to the record will be breaking changes to the clients.