in the Observer (Publish/Subscribe) pattern, are notifications alienmethod calls?

[neuneudr]

First thanks to Lew and Mark who responded to my question about
@ThreadSafe / FindBugs...

Now I've got other questions:

- In the Observer (aka Publish/Suscribe) design pattern, the
notification about the observed subject state change is named a
"callback" right? (terminology question)

tmp.registerObserver( new Observer() {
public void subjectHasChanged() {
// do something now that we know the subject
we were observing changed
}
} );

- 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?

 

[Lew]

Yes. Your class invokes a method whose definition is not under your
control.

Perhaps. The definition might be under your control. It's still good policy
to keep the callback out of the critical section even if it doesn't break
thread safety.

 

[markspace]

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.

 

[Arved Sandstrom]

Not to mention Brian Goetz, who also responded recently. (Take a look
at the cover of your Java Concurrency in Practice book, neuneudr. )




That's one name, sure. I think folks would understand you if you did
call it a "callback."




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.

I think the meaning of "alien" in this context is more restrictive. The
term "alien method" doesn't exactly show up a whole bunch in the
literature, so we may as well run with Josh Bloch's definition, which is
that an alien method is one where our class has no control over it _and_
our class has no idea what this other method does. Examples are public or
protected methods that can be overriden, or methods provided by clients as
function objects.

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.

AHS

 

[markspace]

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.

 

[Lew]

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.