> What happens here? Well it doesn't matter to the caller, they know they get a new ImmutableState back, and if they chose to ignore it then the original state object they passed in will be unaltered.
Yes if they choose, but how are they supposed to make this choice? :)
You can't make an informed decision about it UNLESS you know what is the difference between ImmutableState instance returned by DoSomething and the original one.
We're back to the same problem, then. We can't be sure what DoSomething does without peeking into its implementation.
That it produces another instance in process may be nice, but the core problem is the same.
Can I know for sure how the state of my MutableState object changed?
Can I know for sure what is the difference between the ImmutableState I passed to you and the other ImmutableState you made me pull out of your blackbox? I'm flying blind just the same
> It also allows for free transactional behaviour with rollbacks, which can be super useful:
Agreed, but there is more than one right way to achieve it. This could be also done with mutable objects and deep copies. Just make yourself a backup clone before you go wild.
The cost of your approach is that all behaviour and logic is moved into some ImmutableLib class, so you're creating various "Libs", "Managers", "Services" and the like, which means that you're essentially writing procedural code.
This OOP anti-pattern is known as anemic domain model.
Thanks for the link to Rich Kickey's presentation, it seems to be some food for thought. I'll watch it when I have some free time on my hands and maybe it will affect the way I see it.
Yes if they choose, but how are they supposed to make this choice? :)
You can't make an informed decision about it UNLESS you know what is the difference between ImmutableState instance returned by DoSomething and the original one.
We're back to the same problem, then. We can't be sure what DoSomething does without peeking into its implementation.
That it produces another instance in process may be nice, but the core problem is the same.
Can I know for sure how the state of my MutableState object changed?
Can I know for sure what is the difference between the ImmutableState I passed to you and the other ImmutableState you made me pull out of your blackbox? I'm flying blind just the same
> It also allows for free transactional behaviour with rollbacks, which can be super useful:
Agreed, but there is more than one right way to achieve it. This could be also done with mutable objects and deep copies. Just make yourself a backup clone before you go wild.
The cost of your approach is that all behaviour and logic is moved into some ImmutableLib class, so you're creating various "Libs", "Managers", "Services" and the like, which means that you're essentially writing procedural code.
This OOP anti-pattern is known as anemic domain model.
http://www.martinfowler.com/bliki/AnemicDomainModel.html
Thanks for the link to Rich Kickey's presentation, it seems to be some food for thought. I'll watch it when I have some free time on my hands and maybe it will affect the way I see it.