Campbell Ritchie wrote:A private nested class (not “static inner”) is not necessarily immutable. What will happen if somebody else starts to maintain your class and doesn't understand they shouldn't alter the state of instances of that class?
Campbell Ritchie wrote:What if it implements an interface and you return a reference to outside your class?
You are like my mentor. He thinks that competent people will use code correctly.Avor Nadal wrote: . . . I think that someone would (should) understand the code in such a narrow scope, Right? . . .
Campbell Ritchie wrote:You are like my mentor. He thinks that competent people will use code correctly.
Unfortunately I am a cynic of the worst kind and assume people will get things wrong. I think we are probably both right from our own starting points
Dave Tolls wrote:You can't make it immutable anyway, at least not as far as its use inside the class it is declared
Campbell Ritchie wrote:Unfortunately I am a cynic of the worst kind and assume people will get things wrong....
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Avor Nadal wrote:
Dave Tolls wrote:You can't make it immutable anyway, at least not as far as its use inside the class it is declared
I think that I can. What I've been doing until now has been creating nested immutable classes and assigning the values to their final fields through the constructor. It forces me to write an explicit constructor, of course. That's why I'm saying that my code looks like a little bloated now. For example, if I converted my example this way, it would look like this:
You can protect your code against mistakes, but not against idiotsAvor Nadal wrote: . . . someone who were maintaining my class . . . could go and edit the own nested class, removing the final modifier in one of its fields, . . .
Avor Nadal wrote:I still have doubts about whether to make these type of nested classes immutable, though. I understand that making them immutable, as I already do, has the benefit that no one can change the value of any of its fields once the instance has been obtained...
That would be very different if the nested class inherited from a public class or implemented an interface, because it could "escape" from this very specific context and be altered by an external method. But I insist in that I'm talking about nested classes which mere function starts and end there, in a private method.
Campbell Ritchie wrote:You can protect your code against mistakes, but not against idiots
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:... nothing can protect your code from an idiot developer.
Winston
Because I have finally managed to divert such attention from myselfDave Tolls wrote: . . .
What's everyone looking at me for??
:?
Winston Gutkowski wrote:There's actually a bit more to it than just that. Immutable classes can also share internals, and even cache values, which is one of the reasons that most of the Java wrapper classes have one. They're also usually inherently Thread-safe, which can be one less thing to worry about.
Winston Gutkowski wrote:I think, before I did, I'd ask myself: Why do I want to make this class mutable? Especially if it already works fine as an immutable one. I have to admit to a slight bias here, but I generally follow Josh Bloch's advice to "favour immutability", unless there's some overriding reason why I shouldn't.
Avor Nadal wrote:My motivation is code clarity. Because when I use an immutable class, it requires declaring a new local variable for each field before calling the constructor. Having to be so redundant about the types (first with the fields, later with the constructor and finally with the local variables) makes my code harder to read in my opinion.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Really? Surely those classes, however they're designed, are still going to have to set those values? Either Bean-style, or possibly "Builder"-style (ie, with chained setters). I have to admit to liking the latter approach, but I'm not sure it would convince me to make a class mutable when there's no good need. I also doubt it would make then any smaller than they are now.
Winston
Avor Nadal wrote:Finally I've decided to leave them as immutable and take advantage of the tools of the IDE to navigate through my code in a simpler way ;) .
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |