I want to understand the details of call back methods. however I keep failing to understand the concept of call back methods even after going through some articles. so I guess I am not really able to relate it something practical.I understand that methods like readObject and writeObject are call back methods and are useful while implementing serializable but somehow I feel there is something missing which is making this topic of callback difficult to understand and grasp. If I can be given example of something with which I can relate call back method, it will be useful
There are times when you want one Object to know something has happened in some other location - an event that you don't know when it will happen, but need to know at the point of time it does, so your program can react to it and do some work. To solve this dilemma you use callbacks - or in Java we usually use listeners.
A simple example would be an ActionListener. In a GUI application you want to perform some action when the user presses a button. You don't know when the button will be pressed so you generate a Listener (ActionListener) with a callback method (actionPerformed). When the GUI sees a user click the button it calls the actionPerformed method in your listener so you can do the work you need to do in response to the user's button click.
Joined: Jan 29, 2009
so can we say that call back methods are kind of using observer pattern?
nitinram agarwal wrote:so can we say that call back methods are kind of using observer pattern?
No, but we can say the Observer Pattern uses callbacks.
Callbacks can be used in many other circumstances other than the event dispatching I described above. The example you provided with serialization calling writeObject isn't really an observer paradigm, it is more like a dependency injection. In this case, the ObjectOutputStream knows generally how to serialize an Object into a byte stream, it just doesn't know how to do it for your particular class. So the 'call back' to writeObject() is used to provide the specifics that ObjectOutputStream doesn't know how to do.
Callbacks are used so often it is hard to come up with a broad enough description that covers all the bases. To generalize like this:
1) One Object (the Caller) knows part of what needs to be done, perhaps the 'when', 'where', or 'in what order'. It doesn't know the specifics for some of the work, though.
2) A second Object (the Callee) knows part of what needs to be done, usually the specifics of the work (or some part of the work) to be done, but doesn't know the 'when' or 'where'.
3) So to combine the specifics the Callee knows, and the operations the Caller knows, the Callee gives the Caller a function (the CallBack) so the Caller can tell the Callee when to do its part of the work.
The benefit is you can have one generalized Caller that 'knows the system' without having to subclass it for each specific task to be done. You can have very simple Callees that can perform the task, without having to implement a more complex process.