Re: in the Observer (Publish/Subscribe) pattern, are notifications
alien method calls?
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