That kind of arrangement sounds familiar to me. The mutable versions are used for write operations (e.g. the user changing data through a web page), the immutable versions for read-only operations (e.g. performing calculations, generating reports etc). In my scenario I have the added problem that the mutable versions are by far the more common throughout the codebase, and I use a mutable->immutable converter for trying to wean bits of the code off the mutable versions when they don't need them. It sounds like you're in a better position, where you can make the choice of immutable/mutable to begin with.
If you want to have data changing in-place in your database, rather than a "clone with modifications and deactivate the old" model and you want to use the mutable versions in your code, then I don't see a way around having the different classes. Another approach would be to only deal with the immutable versions in your domain logic, and use something like the repository pattern to modify the mutable object when you want to persist it. I don't know if Hibernate is your ORM framework, but it has a feature I found handy for fetching immutable objects, the "select new" syntax. A tangential point, but there's other (better?) reasons to have immutable objects than just being thread safe, and that is how much easier it is to reason about them. And finally, on a shamelessly self-promoting (some may say 'shilling') note, if you want a way to automatically check your classes are/remain immutable, check out my project here: http://code.google.com/p/mutability-detector/ Kind regards, Graham Allan -- 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.
