Preface

The idea for this book grew out of work on one of my open-source projects. The project had a data-processing workflow that resembled a pipeline. Objects passed through several stages, with their state repeatedly transformed and modified along the way. Memory usage in this workflow once grew abnormally high. After refactoring it to use immutable types, I saw clear improvements in both overall execution speed and memory usage.

That refactoring worked well. But switching to immutable types will not always make a program faster or reduce its memory usage. The experience led me to write this book about the techniques and tradeoffs of immutable data design for developers working with data transformations and changing state.

With today’s LLMs (large language models), a developer might simply tell an AI agent, “Refactor some of the classes in this project into immutable types,” and have the agent complete the refactoring and write the related tests.

But how can a developer decide which parts of a project should use immutable design? What benefits should they expect? How can they verify those benefits? And how can they judge whether the approach the AI takes is appropriate?

I believe that even when AI handles all implementation and testing, developers still need to evaluate design decisions. They need to know what they want to improve and use the results to judge whether the approach taken is appropriate. This book aims to help readers develop that judgment.

For experienced C#/.NET developers, this book also offers an opportunity to revisit familiar code. Who creates the data? Where does it change? Which workflows share it? Starting with these questions, we can use familiar C# tools to make data and state transitions easier to understand.

C#’s record, init, and pattern matching, together with .NET’s immutable collections, make it easier to think about data and operations separately. Yet knowing the syntax is different from understanding how these tools can improve a design. I hope this book helps narrow that gap.