On 16 February 2011 12:33, Ricky Clarkson <[email protected]> wrote:
> Immutable objects can have behaviour, it's just that they'll tend to > return new versions of themselves with a change rather than mutate > themselves. > Exactly :) For a good example of quite how much behaviour take a look at joda-time: http://joda-time.sourceforge.net/api-release/index.html Adding a month to some DateTime won't make an in-place modification to that instance, but will instead return a new DateTime. Good to know if I want to write something like christmas.plus(Duration.standardDays(12)) Which makes me feel nice and safe. I'd hate to discover that I've inadvertently changed the date christmas falls on! Worse still if this happens on another thread while I'm using the date... The technique is also valid with collections, such as Scala's Seq implementation: http://www.scala-lang.org/api/current/scala/collection/immutable/Seq.html (apologies for the Scala, I had hoped to find a good Java example of this in google-collections, but that API is genuinely anaemic) Actually, one of the main reasons that Scala doesn't use Java's collection interfaces is that they'd force it to also inherit the unwanted mutator methods (that, and the ability to take advantage of extra features in the Scala type system) > Regarding mixed mutability, I don't know the answer, but I tend in the > direction of splitting that into two objects, one that's immutable and > one that isn't. Other considerations may prevent that. > It's best to avoid it entirely, if at all possible. Or at least try to constrain any mutability to the smallest place you possibly can. After all, concurrency is here to stay, so immutability is a very good thing to have. I had some interviews recently where I lacked experience in mocking, > so for job-oriented programming I may be losing out, but I do try to > make sure I don't need to mock, as far as possible, by organising my > dependencies so that tests can be written without 'mocking out the > database', etc. > > It doesn't always work; I actually have a unit test that starts no > fewer than 3 HTTP servers. > That's not a "unit" test, it's an integration test :) > On Wed, Feb 16, 2011 at 11:55 AM, Fabrizio Giudici > <[email protected]> wrote: > > On 02/16/2011 12:34 PM, Ricky Clarkson wrote: > >> > >> If instantiating a real object is a problem (again assuming immutable > >> and without side-effects) then you might need to break up your objects > >> a bit more. > > > > Well, it seems we're talking about simple, immutable objects. Ok. Let's > now > > suppose that we're talking about objects that have partially immutable > > fields and partially not From a style point of view, what one should do? > A > > consistent rule could be "public final fields" for "anything that is > > immutable", not "for anything that is immutable AND is part of an > immutable > > object". > > > > Furthermore, if we restrict immutable objects to the strict meaning of > the > > term, we end up with anaemic objects (that is, things with no state, > > read-only javabeans). I hope that they are very few, possibly only some > data > > types. In a real-world scenario I'm thinking of immutable objects that > have > > also behaviour, relationships with other objects etc... hence the need of > > mocking. > > > > -- > > Fabrizio Giudici - Java Architect, Project Manager > > Tidalwave s.a.s. - "We make Java work. Everywhere." > > java.net/blog/fabriziogiudici - www.tidalwave.it/people > > [email protected] > > > > > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
