106: Multithreading. Call Me Back Please.

Callback methods can also be either synchronous or asynchronous and add a whole new dimension to how you can approach problems. The way I think about callbacks is like this. There’s two sides to a callback. One side defines what the callback should look like. In other words, what are the parameters and return type. This is the side that actually calls the callback method. Then there’s the side that implements the callback method. The callback method needs to follow the guidelines set out by the side that’ll be making the call. After all, if the method doesn’t match, then it can’t be called. So whatever code is actually making the call gets to decide what the method will look like. The whole point of callbacks is to give control to the developer to do practically anything inside the callback. This means that you can normally think of a callback method as a method that you write but that you can give to some other code to actually run. You have synchronous callbacks that never leave your thread. These are just like calling a method that then calls back one of your own methods. And you have asynchronous callbacks that run in their own thread. Listen to the full episode for more or you can also read the full transcript below. Transcript If you haven’t already listened to the previous episode, you’ll probably want to do that first. This episode continues the sync/async discussion. The way I think about callbacks is like this. There’s two sides to a callback. One side defines what the callback should look like. In other words, what are the parameters and return type. This is the side that actually calls the callback method. Then there’s the side that implements the callback method. The callback method needs to follow the guidelines set out by the side that’ll be making the call. After all, if the method doesn’t match, then it can’t be called. So whatever code is actually making the call gets to decide what the method will look like. You may find at least at first anyway that you’ll mostly be implementing callback methods and passing them to some other code to be run. It’s not about your experience level of anything. Although designing a good system that other developers can then use to write their callbacks is more complicated. It’s more about the need. The whole point of callbacks is to give control to the developer to do practically anything inside the callback. To me, that just means that there’s a lot more uses that you can apply callbacks in your code than there are places where you’ll need to be calling them. This means that you can normally think of a callback method as a method that you write but that you can give to some other code to actually run. A good example of this in real life is a company’s standard operating procedure manual. This is a book that lists exactly how to do things step-by-step and is given to employees to follow. It’s usually written by somebody in the corporate office headquarters. If you think about it, a procedure written like this is just like a method in programming. This is a method that was written by one person to be followed by another person. You can do the same thing in programming and then some. Because in programming, you can send your method to some other code that’ll run it later like I just described or you can also send your method to code that’ll run it right away. This gives you a whole new way to think about solutions to problems and allows you to write code that’s more widely applicable. What do I mean? Let’s say you have a bunch of numbers that you need to add together and these numbers are in a collection. By the way, episodes 39 through 46 are all about collections. Alright, so you have your collection. What do you do? Well, you go get the first number then the second and add them, right? Then you go get the third number and add that. And you