The Best Refactoring You’ve Never Heard Of

James Koppel explains defunctionalization and its inverse, showing how to mechanically transform designs between functional and object-oriented patterns.

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.