A couple of years ago, I wrote that The Builder pattern is a finite state machine!. A state machine consists of states and transitions between them. As a developer, I want to make illegal states unrepresentable, i.e., users of my API can’t create non-existent transitions. My hypothesis is that only a static typing system allows this at compile-time. Dynamic typing systems rely on runtime validation.   In this blog post, I will show that it holds true, with a caveat.

Frankel's platform  covers topics related to software development, technology trends, and coding tutorials. Through articles, tutorials, and personal anecdotes, Frankel offers insights into programming languages, development frameworks, and best practices in software engineering. Readers can learn about software design principles, development methodologies, and emerging technologies to enhance their coding skills and build high-quality software applications.

A Java geek

Explores how to make illegal state transitions unrepresentable in a type system using a pizza builder as a model. Compares Python, Java, Kotlin, Rust, and Gleam, demonstrating that static typing is necessary but not sufficient — phantom types combined with extension functions (Kotlin), impl blocks (Rust), or constrained parameter types (Gleam) are needed to avoid combinatorial explosion of builder classes. Java lacks the mechanism to attach methods to specific generic types, making it a poor fit for smart builders. Kotlin and Gleam achieve linear code growth when adding new constraints, unlike Java's combinatorial growth.

Making illegal state unrepresentable