Closures aren't just JavaScript interview trivia

I’ve had many coworkers ask a simple question while interviewing candidates: “What is a closure?” The candidate usually gives a rote memorized answer about closures in JavaScript, and the interview moves on (or in the alternative they answer that they don’t know this one piece of trivia). I eventually became bored with coworkers asking this piece of trivia, so I started adding a follow up question to see if they could describe the use of closures into other languages. After all closures are a property of computational functions and are not just for JavaScript.

That line of questioning wasn’t fruitful. I moved on towards asking more scenario driven questions that would actually match up with what happens on the job instead of programming minutia. I had even forgotten about this since my coworkers also stopped asking the closure question since it wasn’t really revealing anything relevant about the candidate. At least until the idea of a closure in C# came up during a discussion of a bug.

In the system we were working on, there was a quirk with respect to the .Net HTTP Context. If the HTTP Context were accessed after a piece of middleware executed, then the context would be null. A coworker of mine was trying to figure out how to solve a bug where he needed a piece of request data from the HTTP Context in a class that wasn’t a Controller (so he had no access to the Request class either).

I said during stand up that he should able to leverage a class that we bind the data to a context that is fully under our control. Unfortunately, because we had both an application context and an HTTP context, I think some wires were still crossed. He took some time to try and figure out how to implement my suggestion, and came back to me in frustration.

To help my coworker, I leveraged closures as an abstraction to keep from being too specific to the problem. We’re creating our own context that is binding data to our functionality and forming this closer. So if we update the middleware that creates our application context then we’re using the object oriented encapsulation of data to form a closure around the new data that we want. Then we can access the data from the application context without worrying about the HTTP context.

Thankfully taking a moment to explain this problem in detail using the concept of a closure helped my coworker. There’s no guarantee that these kinds of metaphors will work for everyone, but he was able to walk away from the conversation and subsequently solve the problem he was working on. At the end of the day, having problems solved is paramount to esoteric computer science knowledge (I’m just always happy when I can help someone with said knowledge).