DEV Community: Nicola Todorov

Designing with Product and Sum types

Nicola Todorov — Fri, 04 Jul 2025 21:08:10 +0000

Composing types

In the previous article about opaque types we touched upon the idea of make illegal states unrepresentable by asking the simple question:

Are all possible String values a valid email address?

The same question can be asked for more complex types. Those that are composed of other types.

For example how are we going to model playing card?

enum Face { Ace, Two, Three, Four, Five, Six, Seven, Eight, Nine, Ten, Jack, Queen, King }
enum Suit { Diamond, Heart, Club, Spade }
record Card(@Nonnull Face face, @Nonnull Suit suit) {}

Product type

Types that encode and relationship we call product types. In the card example we have a type that contains a Face and a Suit.

There is another way to look at the type. We can think of it as a description of a set of values. Then we can measure the size/cardinality of that set. I annotate size/cardinality of Type as |Type|
For example:

\begin{align*} |Face|&=13 \newline |Suit|&=4 \newline |Card|&=|Face| * |Suit| \newline &= 13*4=52 \end{align*}

Hence the name Product type. If it is not clear why we multiply the size, think of all possible inputs that Card can accept.

But how is that useful?

Well we know that all playing cards are exactly 52 and the cardinality of the Card type is 52 so there is nothing to worry about - all possible inputs create valid playing card.

How about if we want jokers as well? Who doesn't like jokers?

record Card(@Nonnull Face face, @Nonnull Suit suit, boolean isJoker) {}

No brainer, right?

Let's calculate the cardinality of Card though.

\begin{align*} |Card|&=|Face| * |Suit| * |Boolean| \newline &= 13 * 4 * 2 = 104 \end{align*}

Our possible instances are way bigger than the expected 54 cards - 52 playing cards and 2 jokers.

Card illegal = new Card(Face.Two, Suit.Spades, true);

One may argue that this is not illegal card because it is stating which card is being substituted by the joker. However this encoding does not represent our domain correctly. We can reach out to smart constructors to solve this, but we have something more powerful.

Sum types

Types that encode or relationship we call sum types. Your intuition might be I am talking about enums like Face, but those are crippled version of sum type.
Look.

enum Face { Ace, Two, Three, Four, Five, Six, Seven, Eight, Nine, Ten, Jack, Queen, King }
enum Suit { Diamond, Heart, Club, Spade }
enum JokerColor { Red, Black }
sealed interface Card {
    record PlayingCard(@Nonnull Face face, @Nonnull Suit suit) implements Card {}
    record Joker(@Nonnull JokerColor color) implements Card {}
}

We have two types of Card either PlayingCard or Joker. Each variant accepts different type of arguments - better than enums, no?

Since we are calling it sum type it is kind of obvious how are we going to calculate cardinality. Let's compute.

\begin{align*} |Card| &= |PlayingCard| + |Joker| \newline &= |Face| * |Suit| + |JokerColor| \newline &= 13 * 4 + 2 = 54 \end{align*}

While it might not feel like big accomplishment that we are combining sum and product types, notice that:

we can not produce invalid Card
we introduced zero logic
domain is communicated clearly - meaning vs encoding
the compiler will ensure that everybody complies with the domain

Let's see how we can extend this list with

State machines

For that we will need slightly more complex problem. We will continue with cards. But this time we need Deck of Cards:

we can have initial Deck as if it is brand new one
we can have shuffled Deck that is ... well shuffled
and last but not least we can have empty Deck

Expected behavior for a Deck is to:

make InitialDeck of cards
shuffle it before each game
deal from the ShuffledDeck until
we get EmptyDeck

The only addition to our code that seems to be needed is

sealed interface Deck {
    final class InitialDeck implements Deck {
        private final SortedSet<Card> cards;
        private InitialDeck(@Nonnull SortedSet<Card> cards) { this.cards = cards; }
    }
    final class ShuffledDeck implements Deck {
        private final Set<Card> cards;
        private ShuffledDeck(@Nonnull Set<Card> cards) { this.cards = cards; }
    }
    final class EmptyDeck implements Deck {}

    static InitialDeck make() {
        // produce all combinations of Face and Suit - all cards
    }
    static ShuffledDeck shuffle(InitialDeck deck) {
        // pick your favourite shuffling algorithm
    }
    static Deck deal(ShuffledDeck deck, Consumer<Card> consumer) {
        // deal until you can't
    }
}

Good. Now we can think of InitialDeck, ShuffledDeck and EmptyDeck as nodes in state machine while make, shuffle and deal as transition between the nodes.

Now we have enforced all requirements:

there is only one way to create InitialDeck - through smart constructor make
you can create ShuffledDeck only if you have InitialDeck beforehand
you can deal only from ShuffledDeck - dealing from EmptyDeck or InitialDeck would be mistake
you can empty a Deck only if you deal all it's cards

Summary

We saw how using product and sum types we can represent domain knowledge that will further be enforced and illegal states will not be possible. Also if we employ once again the idea of smart constructors we can produce small state machines correctly describe workflow in the domain.

The idea of type algebra and cardinality is quite powerful and we only scratched the surface with this article. If you are hungry for more you can check out:

Algebra and Data Types - awesome article that dives deeper and as final result encodes invariants of red-black tree into a type. How cool is that?
The Algebra of Algebraic Data Types 3 part series that goes as far as differentiating types

Designing with Opaque types

Nicola Todorov — Thu, 03 Jul 2025 20:35:46 +0000

Previously in Designing with types for the working programmer

We have imbued meaning in Email type

record Email(String value) { }

But are all possible String values a valid email address?
Can we enforce validation so that we do not end up with defensive programming?

Sure. Constructor can enforce it.

record Email(String value) {
  Email {
    if(!Pattern.compile( "^(.+)@(\\S+)$").matcher(value).matches()) 
      throw new IllegalArgumentException("Not a valid email");
  }
}

Are we really going to throw exceptions like it is new year?

I summon smart constructor.

class Email {
    private final String email;

    private Email(String email) { this.email = email; }

    static Optional<Email> parse(String email) {
        if (Pattern.compile( "^(.+)@(\\S+)$").matcher(email).matches())
            return Optional.of(new Email(email));

        return Optional.empty();
    }
}

Now the constructor is private. The only way to get valid Email is to go through parse - the smart constructor.
As a consequence the instance of Email is like a boarding pass. It is a proof in itself that the email is valid format. Correct by construction.
This is what they call opaque types and they ...

Make illegal states unrepresentable

This phrase was coined by Yaron Minsky and captures a bit more than we are going experience in this article. Nevertheless opaque types are maybe the simplest incarnation of this idea.
Look!

class Password {
  private final String password;
  private Password(String password) { this.password = passowrd; }

  public static Optional<Password> parse(String password) {
    if(password == null || password.length < 6) return Optional.empty();

    return Optional.of(new Password(password));
  }
}

We can now encode/enforce domain rules like

Password has to be at least 7 chars long
PositiveAmount guarantees non-negative values
DiscountPercentage is within predefined range (0, 10]

Just think about it. With smart constructors we can now encode domain events into our types like VerifiedUser - guarantee identity is confirmed.

In each case the type itself is a proof that something was done.

Conclusion

Wrapper type + Smart constructor = Opaque type
Simple as that.

We traded extra lines of code for:

correctness by construction - illegal states can not be created
business rules encoded in types - guaranteed by the compiler
values with meaning - values communicate intent and what has been done already
no defensive coding - validation as earliest as possible

If you are hungry for more and do not mind some Haskell, you can go ahead and read Parse, don’t validate.
For other resources you can google around for "Make illegal states unrepresentable" or better yet watch the original Effective ML by Yaron Minsky

Designing with Wrapper types

Nicola Todorov — Thu, 03 Jul 2025 16:06:12 +0000

It compiles. It runs. So what's wrong?

Let's start with a puzzle.

void resetPassword(String email) {
    // Logic for sending reset password email
}

What is the problem with this method?
Answer
It might be used like so

resetPassword(user.getPassword());

You might be thinking I've gone off the rails for claiming there is problem in piece of code that has no logic in it, but there is a bug waiting.
If you've spotted the problem you sure know that it will be very embarrassing if you need to fix such a bug.

Let's have another.

record User(String name, String email, String address) { }

What is wrong this time?

Answer
When instantiating, arguments can be swapped around.

new User("todoniko", "Sofia, Bulgaria", "drama@mail.com");

It compiles. It runs. No warnings. No type errors. But the potential for bug is there.

Actually it is a whole class of bugs that the compiler could prevent - but doesn't, because we never told it how.

Addressing the root cause

As with many things in programming we have jargon for this - it is a code smell it is primitive obsession.
We can encode way too many things with a String - password, username, email, file path etc. But all those instances mean different things and communicate distinct purpose. In our heads we infer the meaning from the names and expose the encoding for everyone to (ab)use. We have failed at abstraction.

Let's remedy that by wrapping/hiding the encoding/primitive type and expose only the meaning.

record Email(String value) {}
record UserName(String value) {}
record Address(String value) {}
record User(UserName name, Email email, Address address) { }

void resetPassword(Email email) {
    // Logic for sending reset email
}

What have we achieved?

Now the potential for bugs from passing the wrong argument has come down significantly. When our types are clear, bugs become rare.
Now our types communicate meaning instead of encoding and this is equally useful for both humans and AI agents.

Conclusion

The problem and solution in this article are not novel in any way. Actually they are too old to keep pretending that they do not exist.

I have drawn inspiration from several sources and if you are daring enough to step out of the mainstream languages we use today you can have a look at:

Designing with types: Single case union types (F#)
Haskell mini-patterns handbook (Haskell)
Type blindness (Elm)

Please, don't be primitive.

What is next

In the next article we will upgrade our wrapper type so that we are not going to care if it needs validation. If it exists it is valid. The instance of the type will be the only evidence we need. We will achieve correctness-by-construction with opaque types.

Lamenting about data types

Nicola Todorov — Thu, 03 Jul 2025 04:46:23 +0000

Why most code is more fragile than it should be?

Somewhere, right now, a developer is staring at a failing test or investigating production issue. It will take some time to figure it out. Maybe it was a string or a number passed into the wrong place.
The compiler didn't complain. Neither did the tests - until someone fed it a value they weren't supposed to.
The fix? A few extra if statements. Maybe a test added after the fact.
The underlying cause? Never questioned.

What if I told you ... that bug did not need to exist?
What if your code could make that mistake impossible?
Not caught, not detected, unrepresentable.

I am not talking about science fiction or some weird academic programming language. It's what type systems of Java or C# are already capable of doing - if you let them. Yet most developers treat types like seat belts - annoying at best, restrictive at worst.

Types vs Tests

You've probably heard someone say:

That is why we write tests

Fair enough. Yet let's compare:
A test compares a handful of paths.
A type covers them all.
A test can be skipped or deleted.
A type can't be ignored. (Don't worry TypeScript we love you the way you are)
A test catches problems after you've executed them.
A type prevents you from writing them in first place.

Types are not just for the compiler. They're for you, your teammates, and even your AI agent. They encode knowledge. They reflect rules. They act as living documentation that is always up to date, always enforced and always helpful.

Why isn't everyone doing this?

And this is what keeps me up at night:
We already have the tools. Mainstream languages have type systems that are capable enough. Modern IDEs are fantastic at navigating types. AI coding tools fair better when types guide them.

Yet most teams still passing raw strings around like they're free candy. Still relying on test to catch what the compiler could have prevented. Still debugging issues that shouldn't have been representable in first place.

Why?

Because we humans are inherently sloppy.
We were taught to "just get things working".
We optimized for flexibility and speed - until our systems collapsed under the weight of ambiguity.
We missed the essence:

A good type system doesn't slow you down. It keeps you from speeding into walls.

Plan of action

Over the next few articles, I'll be introducing patterns for type creation that amplify the design process. I will stick to what Java or C# can encode, nothing fancy like dependent types or encoding fizzbuzz in the type system. My aim is practical and applicable.

It is time to stop treating types like red tape. Designing with types won't make you invincible but it will make your code resilient, expressive and correct. Let's start thinking in types.