The Best Refactoring You’ve Never Heard Of

Compose NYC 2019
Speaker: James Koppel

Every problem can be solved by many designs. Often the relation between two designs is that one is a transformation of another. When we understand how to mechanically transform designs, we can more easily explore the design space, and effortlessly identify the tradeoffs.

So, what do these design changes have in common?

Letting a search procedure take an arbitrary filter function, instead of a fixed set of options
Changing a program using blocking I/O to non-blocking I/O with an event loop
Letting a user stop in the middle of an action — and resume it after a server reboot

Answer: They’re all instances of a transformation called “defunctionalization” or its inverse, “refunctionalization.” Come learn how it works, and learn to recognize when a proposed design change is just an instance of this general technique. In doing so, you’ll learn how the tradeoffs between designs can be boiled down into a single slogan: refunctionalized is more open, defunctionalized is more inspectable. As a plus, you’ll also learn how defunctionalization is the oldest technique to compile functional languages.