 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2007Mutable Dimension, argh!
Mutable Dimension Is there anything you do to minimise the impact of this sun gaf? Or indeed any immutable where you have to use that Type.  SignatureMike W > Mutable Dimension > > Is there anything you do to minimise the impact of this sun gaf? > Or indeed any immutable where you have to use that Type. Defensive copying. See Joshua Bloch's /Effective Java/ - there's a chapter on this. SignatureLew >> Mutable Dimension >> [quoted text clipped - 4 lines] > > See Joshua Bloch's /Effective Java/ - there's a chapter on this. I know how to make my own classes. And yes that is my Bible! I have to have Dimension type. I can subclass it and throw Unsupporteds and yes do defensive copying. But then it's a bit unsafe runtime wise when that lurking call to setXXX kicks you. Have I missed something obvious? SignatureMike W >>> Mutable Dimension >>> >>> Is there anything you do to minimise the impact of this sun gaf? >>> Or indeed any immutable where you have to use that Type. "Lew" <lew@nospam.lewscanon.com> wrote >> Defensive copying. > I have to have Dimension type. I can subclass it and throw Unsupporteds and > yes do defensive copying. > But then it's a bit unsafe runtime wise when that lurking call to setXXX > kicks you. > Have I missed something obvious? If you're concerned with other threads mutating your object, use synchronization. SignatureLew >>> Mutable Dimension >>> [quoted text clipped - 11 lines] > kicks you. > Have I missed something obvious? I believe MutableFoo and ImmutableFoo should not extend each other. They fail the IS-A test in both directions (that is, it is not the case that a MutableFoo IS-A ImmutableFoo, and vice versa). For cases where an inheritance hierarchy is desirable, I'd use 3 classes (or 1 interface and 2 classes). public interface Foo { public int getX(); } public class ImmutableFoo implements Foo { private final int x; public ImmutableFoo(final int x) { this.x = x; } public int getX() { return this.x; } public MutableFoo toMutableFoo() { MutableFoo returnValue = new MutableFoo(); returnValue.setX(this.getX()); return returnValue; } } public class MutableFoo implements Foo { private int x; public int getX() { return this.x; } public int setX(final int x) { this.x = x; } public ImmutableFoo toImmutableFoo() { return new ImmutableFoo(this.getX()); } } - Oliver > I believe MutableFoo and ImmutableFoo should not extend each other. > They fail the IS-A test in both directions (that is, it is not the case > that a MutableFoo IS-A ImmutableFoo, and vice versa). Yes I agree but I'm dallying with an unashamed hack due to the existing class. SignatureMike W > Mutable Dimension > > Is there anything you do to minimise the impact of this sun gaf? > Or indeed any immutable where you have to use that Type. I wrote my own class. It doesn't extend MutableDimension, but there is a toMutableDimension() method and ImmutableDimension(Dimension d) constructor for when I need to move from my code to Sun's code and back. - Oliver >> Mutable Dimension >> [quoted text clipped - 4 lines] > a toMutableDimension() method and ImmutableDimension(Dimension d) > constructor for when I need to move from my code to Sun's code and back. Yeah I considered this approach, and I;ve done that kind of thing in the past but at the moment I think I'll just use Dimension for my simple usage. SignatureMike W > Mutable Dimension > [quoted text clipped - 3 lines] > -- > Mike W Whenever passing a Dimension object d to an untrusted method: otherObject.untrustedMethod(new Dimension(d)); >> Mutable Dimension >> [quoted text clipped - 6 lines] > Whenever passing a Dimension object d to an untrusted method: > otherObject.untrustedMethod(new Dimension(d)); I suppose it comes down to, make your own immutable or do as you suggest. instantiation expense vs more complex code. Or do both and provide 2 getters so callers have the choice depending on needs and trust. SignatureMike W > >> Mutable Dimension > [quoted text clipped - 13 lines] > -- > Mike W worrying about instantiation expense (especially in a GUI environment) is just down right silly. 1. Write something that works correctly. 2. Refactor it to be designed well 3.1 If and only if its too slow, profile 3.2 Using profile data, optimize the worst offender (only) 3.3 return to step 2 4. Test code again, Go to Step 1 if tests fail. 5. Ship product, you've done a good job. Always remember the rules of optimization: 1. Don't do it. 2. (For experts only) Don't do it yet. Oh, those rules also apply to abstracting. >> >> Mutable Dimension >> [quoted text clipped - 30 lines] > > Oh, those rules also apply to abstracting. Yes I realise this, but like everything you weigh everything up. I was musing really over the issue and in my circumstance - not library code, there is no real need to copy for safety. What was really required was a true immutable - the advantage I really wanted (of any immutable) was the create once use everywhere [Bloch Item 4]. This would be used by paint code. The above is actually an oversimplification optimisation isn't black or white, and no one in there right mind would suggest coding however elegant that was resulting in disk thrashing or constant GCing. SignatureMike W > The above is actually an oversimplification optimisation isn't black or > white, and no one in there right mind would suggest coding however elegant > that was resulting in disk thrashing or constant GCing. Actually, I do suggest code that one might think would result in "constant GCing", and I aver that I'm in my right mind. More precisely, I suggest that one code without regard for naive and unfounded superstitions about GC. The JVM is designed to be very happy with code that creates myriad small objects of short lifespan. The design principle in Java, if anything, is to avoid creation of huge numbers of long-lived objects. One can avoid most GC issues by being careful to dereference unused objects completely and as early as they're no longer needed. For almost all Java work one can ignore putative GC optimizations altogether. For some applications one can tune the GC algorithms as a deployment matter. I have yet to hear of any where one should actually write code that would avoid "constant GCing". Even if one did, the more elegant one's code, the less likely there is to be a problem. SignatureLew >> The above is actually an oversimplification optimisation isn't black or >> white, and no one in there right mind would suggest coding however [quoted text clipped - 10 lines] > most GC issues by being careful to dereference unused objects completely > and as early as they're no longer needed. Well exactly! A form of optimisation, like I say it isn't black and white! > For almost all Java work one can ignore putative GC optimizations > altogether. For some applications one can tune the GC algorithms as a > deployment matter. I have yet to hear of any where one should actually > write code that would avoid "constant GCing". Even if one did, the more > elegant one's code, the less likely there is to be a problem. This is getting futile, I'm sure we agree. SignatureMike W > > Whenever passing a Dimension object d to an untrusted method: > > otherObject.untrustedMethod(new Dimension(d)); > > I suppose it comes down to, make your own immutable or do as you suggest. > instantiation expense vs more complex code. Like Daniel, I think the chances of the odd extra Dimension object causing performance problems are too low to be worth taking seriously. But I want to add another point: what are the chances that someone will abuse the mutable Dimension object ? There are undoubtedly situations where defensive programming /would/ be worthwhile, but I think that in the majority of situations, the chances of abuse are also too low to be worth taking seriously. I.e. Don't bother unless you need it, and if you /do/ need it, then there's little point in worrying about the performance cost because you can't avoid it. -- chris Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.