I was just recently mulling over how interfaces (Java-style) for data types are pretty much always the wrong thing to do.
Putting an interface means losing a resolution on something. Now you have to talk to it through a generic approximation. The benefit of that - you can now talk to anything that implements that interface, which means an open set. Anyone can come and add a new thing that implements that interface and it will work, without changing a line of code. Drawbacks: All the additional information about that thing is lost, and you have to come up with that interface which is not a trivial task. As the business logic changes, such interfaces often need to be revised. And as any abstraction and indirection - it introduces some confusion and mental tax.
In a typical business setting, data shape type is almost always a closed set. Even if you have N versions of some you want to support, you don't expect random external developers to add more, without altering the broader code around it. The closed set of allowed formats can just be expanded, new cases handled and the job is done. And business logic is never as simple as we would like and very often requires conditional handling, which is just painful to express via interfaces. A "switch statement" is more flexible and can do whatever without bothering with defining a contract between the data and the code using it.
While there are exceptions and it is all context-dependent, as a rule of thumb, avoid stuffing your data with interfaces, and use sum types.
#oop #programming #software