I agree with Steve. Personally speaking,I find immutable objects a lot easier to deal with (test, grok, read), most of the time. The objects themselves don't necessarily have to BE immutable, but it can help if you think of an object as immutable.
Use case: We have an Account (persistent object) for which we bill at the end of the year, and various other situations, such as a transfer of ownership. We have a calculation engine which calculates what an invoice should be for the Account. We need to update the Account with the results of that calculation. The calculation engine has lots of deep and dark magic. We show the user what the results will be for a particular operation, and the user can cancel an operation. Obviously, if the operation is cancelled we don't want to update the account in any way. For a transfer, we have two calculations with different parameters for the same Account, for the old and new owner. We had two options: 1) Update the account directly in the calculation engine. Plus points: simple to understand, minus: we have to reread the account from the database each time we do a cancel. Worse, for a transfer, we have to do funky stuff to ensure that both calculations can happen on the same Account without one affecting the other. 2) In the calculation engine, assume that the Account object is immutable, and cannot be changed. The engine returns a (new) Calculation object for each call. Plus points: This makes multiple calculations on an Account much easier to manage. We can cancel a calculation much more easily. When reading the code, we know exactly what the calculation engine does: it creates the Calculation object. The results of a calculation are a Calculation object, not an updated Account. This makes it easier to grok, and also easier to test. Minus points: less performant. 1) is clearly more performant than 2. 2 has more code (we have to update the Account object outside the calculation engine), and will be slower (creation of a Calculation object, more passing around inside the calculation engine). However, 2 is a much better solution. It has more safety (persistent objects not updated until after user confirmation), testability (we have to compare the Calculation object, not Account), we can reason about it. Please note that Account is not actually immutable (it's an object persisted to the database using hibernate, there are lots of getters & setters involved). Calculation IS, but only to make subsequent use of the object more secure, and it's not persisted. When I consider immutability, I'm not usually concerned about performance, or multi-threading, it just helps me think a bit clearer. Even thinking of something as immutable can lead to a better solution. It's one more tool in the box. Have fun. Matthew. 2011/6/21 Steve Lindsay <[email protected]>: > On Jun 21, 3:01 am, Kirk <[email protected]> wrote: >> >> Again, I'm not against immutability, it just seems that we've all picked up >> on that sound bite and have forgotten all of the other colors that make the >> world interesting. >> > > Hasn't most of the immutability push (outside of this thread at least) > been about safety, maintainability, ability to reason about complexity > etc., rather than performance? > > - Steve -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
