When you're defining an interface on a type that doesn't need to appear in its own method parameters or return types, and where the actual type doesn't matter (as in classic OOP), Java interfaces are fine. But not all problems are best framed this way.
But I'm curious if you don't find object algebras in Java cumbersome and kind of fighting the type system? Because while I like this kind of thing in Scala, in Java it feels very much against the design of the language.
I agree, I prefer sum types in general. And you can still get dynamic dispatch from trait objects (in Rust), so you have both approaches at your disposal. (In Java, all you have is a hammer...)
> But I'm curious if you don't find object algebras in Java cumbersome and kind of fighting the type system?
Yes and no. I try to use them where they make more sense than OO-style interfaces, so somewhat by definition I don't find them any more cumbersome than OO-style interfaces would be. Java feels like it has a dearth of modeling techniques, so even a seemingly-niche one like object algebras gives me a lot more to work with.
Serializers/deserializers are a good fit for an object-algebra approach, since you don't want to define those methods directly on the data type you're serializing (if you even have control over that type).
Traditionally algebraic types, where you can combine two instances to get a third, are also a good fit. (From a Haskell perspective, you can think of the `x.add(a, b)` as explicitly naming the dictionary of typeclass methods you'd get from writing `a + b` -- kind of like `a +_x b`, if you will.)
And there's almost no choice if you want to define a signature over multiple types -- you need a mediator object anyway.
It's pretty ergonomic if you stay nearby these and similar patterns.
> The expression problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).
Why should I care about recompiling? That's an implementation detail.
Taking the compilation stuff out, it looks very similar to classy lenses.
Sometimes you don't have access to 3rd party src code you call into, hence why you can't always modify and recompile it.