in the Observer (Publish/Subscribe) pattern, are notificationsalien method calls?
in [Java Help]
|
Prev: in the Observer (Publish/Subscribe) pattern, are notifications alien method calls?
Next: inheriting a main method
From: markspace on 13 Sep 2009 15:17 neuneudr(a)yahoo.fr wrote: > First thanks to Lew and Mark who responded to my question about > @ThreadSafe / FindBugs... Not to mention Brian Goetz, who also responded recently. (Take a look at the cover of your Java Concurrency in Practice book, neuneudr. ;) ;) ;)) > - In the Observer (aka Publish/Suscribe) design pattern, the > notification about the observed subject state change is named a > "callback" right? (terminology question) That's one name, sure. I think folks would understand you if you did call it a "callback." > > - In the Observer (aka Publish/Suscribe) design pattern, can't it be > said that the notification about the observed subject change is an > alien method call? Yes, I'm sure it is. When all is said and done, the moment you call some other object's methods, that's an alien method call.
From: markspace on 13 Sep 2009 15:55 Arved Sandstrom wrote: > IOW, just calling another class' methods is not necessarily an alien > method call. For example, the method called cannot be overridden and we > know what the implementation does. Weeeeelllll..... I accept in principle what you are saying. However, even if we know what an implementation does today, that doesn't mean said implementation will do the same thing later. It could be changed (even inadvertently). I agree that your chances of avoiding this sort of are not zero even if the method is not alien (it's a private method in your class). However, I think the chances go up the more public a method is. Even a package private, final method might get co-opted for some other purpose (it happens, since the method is no longer totally private for one class) and that could end up breaking some needed, subtle, thread safe requirement. I think the best design doesn't rely on non-private methods at all for thread safe behavior. I agree this isn't always possible in practice; all designs are compromises to some extent.
From: Lew on 13 Sep 2009 20:58
Arved Sandstrom wrote: >> IOW, just calling another class' methods is not necessarily an alien >> method call. For example, the method called cannot be overridden and we >> know what the implementation does. markspace wrote: > Weeeeelllll..... I accept in principle what you are saying. However, > even if we know what an implementation does today, that doesn't mean > said implementation will do the same thing later. It could be changed > (even inadvertently). You can say the exact same thing about private methods of the class itself. It's a no-op criticism. > I agree that your chances of avoiding this sort of are not zero even if > the method is not alien (it's a private method in your class). However, > I think the chances go up the more public a method is. Even a package > private, final method might get co-opted for some other purpose (it or a private method in the class > happens, since the method is no longer totally private for one class) > and that could end up breaking some needed, subtle, thread safe > requirement. Programmers can make mistakes, in other words. > I think the best design doesn't rely on non-private methods at all for > thread safe behavior. I agree this isn't always possible in practice; > all designs are compromises to some extent. The extension of your thesis is that best design doesn't rely on methods at all for thread-safe behavior. If another class is written to have immutable instances, you can use it. If another class doesn't make any changes to the state of the calling class, and is itself thread safe, you can use it. If the other class has only package-private, final methods, you can use it. None of this is any more dangerous than using private methods within the calling class. There are other reasons to keep the foreign (since "alien" has a particular method as pointed out by Arved) method out of the critical section. Just because a call is thread safe doesn't mean it belongs in the critical section. -- Lew |