Is 'design with types first' ultimately the same as 'design with interfaces first'?

Question

In Object Oriented Programming, we're taught to think in terms of Polymorphism (the idea that the implementation is decoupled from the interface - and that it makes sense to think of the interface first).

This is expressed by Eric Gamma (author of Gang of Four Design Patterns Book)

Program to an interface, not an implementation

Later we learned that this is a way of solving The Expression Problem.

Other languages such as Clojure address 'The Expression Problem' using protocols.

Now coming out of Scala (and perhaps influenced by Haskell) we're seeing a design movement that says "Design your Types First". When I heard that - I thought I'd heard it before.

My question is: Is 'design with types first' ultimately the same as 'design with interfaces first'?

Answer 1

In Java-like languages, interfaces describe object types, classes describe abstract data types. "Design with interfaces first" is not the same as "design with types first", simply because in a Java-like language classes (and primitives) are also types (but not object types). So, "design with interfaces first" really just means "do OO".

However, "design with types first" doesn't exactly mean what you think it means. The idea is that you use types to model your problem domain and let the types drive the design and development. It's more analogous to TDD in that sense: in TDD, the tests tell you what to do next, they tell you what to do, they tell you how to do it, they tell you what your design is, they tell you how to structure your code, and they tell you when you are done.

I would call it maybe Type-Driven Development (which conveniently and confusingly can also be abbreviated to TDD), because you use types in the same way that you use tests in TDD. It's not about designing with types first, it's about the types driving everything – designing them first is merely a prerequisite for that.

Answer 2

A small case study: a pattern matcher in two pseudo-languages, first OO and then functional

In OOP, designing interface-first

interface IPatternMatcher {
    bool Match(string toMatch)
}

The above is the only interface we need, but it doesn't really give us any clues about how to design our implementing types. You will probably want some composites, so you implement an OrPatternMatcher

class OrPatternMatcher : IPatternMatcher {
    OrPatternMatcher(list<IPatternMatcher> submatchers);

    bool Match(string toMatch) {
        return _submatchers.Any(s => s.Match(toMatch));
    }
}

But now you have started implementing functionality, without having finalised your hierarchy. It is kind of impossible to separate these two stages in OOP because your functions and types are so intertwined

---

In FP, designing type-first

type PatternMatcher =
| OrPatternMatcher        : list<PatternMatcher>
| AndPatternMatcher       : list<PatternMatcher>
| SubstringPatternMatcher : string
| RegexPatternMatcher     : regex

Here, we have all the necessary types designed up-front, covering all the cases you can think of. The PatternMatcher union type in FP is related to the IPatternMatcher interface OOP, with the crucial difference that the union declares its type structure with no functions, whereas the interface declares its functions with no type structure.

It is now trivial to implement a match function just by looking at the shape of the types you have laid out. If you have designed the types sensibly for your domain, you are already most of the way to having a working component. This is what it means to design your types first - to accurately model your domain without worrying about behaviour

In my opinion OOP interfaces and FP types are almost the opposite of each other, and the benefits gained from designing your FP types up-front are very different to those gained by programming to an interface.

---

As an additional afterthought, the phrase "design your interfaces first" is not the same as "program to an interface" and so the latter cannot be truly compared to "design your types first".

• "program to an interface" advocates the decoupling of components by not assuming implementation details
• "design your types first" is advice on modelling your domain sensibly before implementing behaviour

The two really aren't that comparable, as they relate to different situations

Answer 3

First things first, I don't see how programming to interfaces addresses the expression problem.

In short, the expression problem states that you can only add new data or new functions to a datatype (without recompiling) - not both.

Programming to most interfaces lets you make new functions that use that interface, but you can't add data to the interface without recompiling it.

Now, on to the meat of the question:

Is 'design with types first' ultimately the same as 'design with interfaces first'?

Not quite.

Design interfaces first implies you approach the design from how it's going to be used, rather than how it's going to be implemented.

Design types first implies that as well, but in a language like scala some of the implementation details will impact how it can be structured. Are you going to use structural types? Are you going to use case classes? Are you going to mix in some traits? How you slice the reusable parts will change how you present the interface for the code's use.