Just a concurrent programming or a occupation interview subject in the past, day to day class plan practice now. For many teams “immutable first” becomes the norm not only for Value Objects or functional paradigm. It’s a natural consequence of constructors’ existence. Software is more and more complex, there is no place for additional effort just for objects’ state tracking. Despite everything, you can hear objections or whispers of temptation: “It can’t be immutable due to the framework”, “Don’t do it here, it is just an entity/service/DTO”, “We don't request another annotation, 5 on each field is enough”. I'll dispel these myths and show how to make popular Java libraries large tools again (persistence, serialization, mocks and other). They won’t tell you more how to code. alternatively of writing God Classes, be a god of your code and compose immutable classes whenever you want
GeeCON 2022: Tomasz Skowroński - Are immortal libraries ready for immutable classes?
Just a concurrent programming or a occupation interview subject in the past, day to day class plan practice now. For many teams “immutable first” becomes the norm not only for Value Objects or functional paradigm. It’s a natural consequence of constructors’ existence. Software is more and more complex, there is no place for additional effort just for objects’ state tracking. Despite everything, you can hear objections or whispers of temptation: “It can’t be immutable due to the framework”, “Don’t do it here, it is just an entity/service/DTO”, “We don't request another annotation, 5 on each field is enough”. I'll dispel these myths and show how to make popular Java libraries large tools again (persistence, serialization, mocks and other). They won’t tell you more how to code. alternatively of writing God Classes, be a god of your code and compose immutable classes whenever you want