I have some misunderstanding about terms of delegates and callbacks in Java.
class MyDriver {
public static void main(String[] argv){
MyObject myObj = new MyObject();
// definition of HelpCallback omitted for brevity
myObj.getHelp(new HelpCallback () {
@Override
public void call(int result) {
System.out.println("Help Callback: "+result);
}
});
}
}
class MyObject {
public void getHelp(HelpCallback callback){
//do something
callback.call(OK);
}
}
Is it callback or delegate (Are delegates and callbacks the same or similar?)?
How to implement then another one?
What you want to achieve is bidirectional communication between the original caller and a service while avoiding the service to depend on the client. The pattern you use for that goal often depends on the restrictions of your language. You use function pointers, closures or, if you have none of these, callback objects (which might also be seen as closures).
And then there are often lots of different names for the same or a very similar pattern.
This is a callback. According to Wikipedia:
So let's look at the executable code:
Here, the
callback
argument is a reference to an object of typeHelpCallback
. Since that reference is passed in as an argument, it is a callback.An example of delegation
Delegation is done internally by the object - independent of how the method is invoked. If, for example, the
callback
variable wasn't an argument, but rather an instance variable:... then it would be delegation.
Here,
MyObject
uses the strategy pattern. There are two things to note:getHelp()
doesn't involve passing a reference to executable code. i.e. this is not a callback.MyObject.getHelp()
invokeshelpStrategy.getHelp()
is not evident from the public interface of theMyObject
object or from thegetHelp()
invocation. This kind of information hiding is somewhat characteristic of delegation.Also of note is the lack of a
// do something
section in thegetHelp()
method. When using a callback, the callback does not do anything relevant to the object's behavior: it just notifies the caller in some way, which is why a// do something
section was necessary. However, when using delegation the actual behavior of the method depends on the delegate - so really we could end up needing both since they serve distinct purposes:I'd argue that "callback" is a name for a generic pattern where you provide the module you're calling with a a way for said module to call your code. A C# delegate, or an ObjC delegate object, (these two being entirely different beasts) or a Java class-implementing-the-callback-interface are different, platform-specific ways of implementing the callback pattern. (They can also themselves be considered patterns.) Other languages have more or less subtly different ways of doing so.
The above concept of "delegate" is also similar to the Strategy pattern, where the delegate can be thought of as one. Similarly, a Visitor is also a type of callback. (A visitor is also a strategy for processing each visited item.)
All this is using definitions that are intuitive to me, and might not be to anyone else, because neither "callback" or "delegate" are formal terms and it makes little sense to discuss them without referring to a previous definition thereof that's valid in your context. Consequently it makes little sense to ask what the definition is since, to the best of my knowledge, there isn't an authoritative one. To wit, the fact that other answers to this question are likely to say something entirely different.
My recommendation would be to focus on the merits of your design – whether it achieves what you need, doesn't introduce tight coupling, etc. – rather than on minutiae of semantics. When two design patterns appear similar, they probably can be used to achieve similar goals equally well.