Async OOP 0: Introduction

As programmers adopt async, eventually they come across problems trying to fit asynchronous code into OOP (classical OOP, that is). The root cause of this is that asynchronous code is naturally functional. And by “functional”, I don’t mean “working”. I mean the style of programming where behavior is paramount and state is minimized.

This is the first in a series of posts that will examine combining async with OOP.

Async is Functional

Historically, async can trace its roots (or at least one major root) back to F#’s asynchronous workflows, but this is not what is dictating the functional nature of async.

All asynchronous code is functional by nature. I used to teach asynchronous programming (in C++, then in C#, well before async), and one of the key pieces of advice for writing asynchronous code is: “you have to turn your mind inside out.” That’s regular-person-speak for “think functionally, not procedurally.”

The major breakthrough with async is that you can still think procedurally while programming asynchronously. This makes asynchronous methods easier to write and understand. However, under the covers, asynchronous code is still functional in nature; and this causes some problems when people try to force async methods into classical OOP designs.