Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Best way to prevent access to a nulled reference

 
Wilfried LAURENT
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To make it short, I have a reference t1 on an instance of class Toto.
By some means, a client get a hand on t1 and stored it in t2. Then t1 is nulled. But, of course, t2 still has access to the reference.
What is the best way to prevent such situations (Proxy pattern?).
Thanks
W.
 
Junilu Lacar
Bartender
Posts: 7483
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two things you could do:
1. If appropriate, make access to t1 more restrictive,
2. Assuming that Toto is Cloneable (with clone() overridden to perform a "deep copy" if necessary), instead of returning a direct reference to the object, return a reference to a clone of the object:

 
Wilfried LAURENT
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By "make access more restrictive", do you mean that I should return a fake object, like a Proxy or an Adapter?
What I want to do is to have a "master" reference (t1) and secondary references (t2), which behaves the same as t1 as long as t1 is alive. When t1 is set to null by the master, all the other references should be sort of disactivated. In that case, cloning should not be the solution.
W.
 
Junilu Lacar
Bartender
Posts: 7483
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Wilfried LAURENT:
What I want to do is to have a "master" reference (t1) and secondary references (t2), which behaves the same as t1 as long as t1 is alive. When t1 is set to null by the master, all the other references should be sort of disactivated. In that case, cloning should not be the solution.

Smells like you're breaking encapsulation there. At any rate, you could try implementing a registration/notification scheme similar to that used in by Events/Listeners. I.e. clients register themselves as listeners with the master. Before the master deactivates t1, it notifies all registered listeners that t1 is deactivating. Upon receiving notification, listeners are responsible for deactivating their own references to the "master" object.
HTH,
Junilu

 
Wilfried LAURENT
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your answer.
If I understand you well, you recommand to use a "pseudo" javaBeans framework.
Anyone interested in "master" information should be registered and anyone modifing an information (setting a ref to null e.g) should use the setters so that any registered client are aware of this modification. Am I right?
W.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic