> If someone passes in a final FooBar to a method, and you mutate the FooBar during the method for any reason, then after the method is done the object remains mutated.
Fair enough, but if FooBar is your class there's an easy fix for this - make FooBar immutable. If it's not, make an immutable wrapper object for it.
Very true that relying on untrue assumptions about the immutability of your data will cause hard-to-spot bugs, but the solution is then just to guarantee everything is immutable, and define that as an assumption that cannot be false if everyone on the team follows the pattern.
If somebody does break the pattern, then that, rather than the race condition down the line, is the real bug. The dev who wrote the mutable data class can just have that (re-)explained to them, so it doesn't happen again.
Fair enough, but if FooBar is your class there's an easy fix for this - make FooBar immutable. If it's not, make an immutable wrapper object for it.
Very true that relying on untrue assumptions about the immutability of your data will cause hard-to-spot bugs, but the solution is then just to guarantee everything is immutable, and define that as an assumption that cannot be false if everyone on the team follows the pattern.
If somebody does break the pattern, then that, rather than the race condition down the line, is the real bug. The dev who wrote the mutable data class can just have that (re-)explained to them, so it doesn't happen again.