Question about the Observer Pattern
Hello everyone!
I am currently designing a class which overrides a Swing component and in order to achieve what I want, I have registered a Listener on that Swing component. In order to respect encapsulation, should I override the corresponding getListeners method and remove my listener from the returned list so that it becomes impossible for an external class to find out my listener and remove it?
Thanks for your advice
[443 byte] By [
Dalzhima] at [2007-11-27 6:38:16]
> should I override
> the corresponding getListeners method and remove my
> listener from the returned list so that it becomes
> impossible for an external class to find out my
> listener and remove it?
>
> Thanks for your advice
Actually, by doing this, you would be violating encapsulation.
By asserting that someone else removing your listener would be a break in encapsulation also would suggest that you would consider breaking into Swing's private objects to be a break of encapsulation. Besides, you can protected it all you want, and somebody can use reflection and have their way with your class anyway.
And why would anybody else want to scheme on your listeners? It seems like an inordinate amount of work to do something with very little yield.
Well, you never know! Some guy could use the following piece of code:
Listener[] listeners = THEObject.getListeners();
for(Listener listener : listeners) {
THEObject.removeListener(listener);
}
Of course there would be no bad intention behind this! He might be thinking he knows he's the only one who added listeners and thus wants to remove all of them. But that would break my class!
> Well, you never know! Some guy could use the
> following piece of code:
I'd probably have to know why that rogue coder was in my JVM :). And if this person has access to your listeners, there is a whole lot more stuff that he or she has access to that could be quite a bit more damaging.
> Or that my code is in his JVM! >:]
> My subclass is actually meant as a tool to use by
> other developers. So that's why I wanted to make it
> as robust as possible.
I look at it thusly:
I provide software for other coders to use for their own benefit. I'll provide some documentation which serves as a contract, stating how it is to be used. If they decide to use it incorrectly, then that is their business. They will either receive more or less benefit from it, neither or which is really my problem or concern.
If they're messing with my data, then that's a different issue, and protecting calls with weak, devious tactics is simply a no-win situation. I'd be employing an RMI-type scheme in that case, and an API in that way can be designed to be secure and tamper-proof.
