Scala and interfaces

Question

In Java I would typically declare my entire domain as interfaces, possibly with some kind of Factory to get me implementations. This is partly because I am so old I can remember when some persistence layers required implementation classes to subclass a specific class but also so that I can easily:

• mock objects for testing purposes
• proxy objects at runtime if necessary
• provide different implementations

I follow this practice even when I don't really envisage that I'll actually want to do any of the above; I still believe it to be good practice just in case. I think it's a fairly common approach.

Would this be unusual in Scala-land if I declare all domain objects abstract? Do the points above hold for Scala as well?

Answer 1

Scala has traits, which are interfaces on crack. Really, they're what interfaces should have been, admittedly, there are limitations when it comes to constructors, but that's not really a big deal considering the fact that if you have two interfaces both having requirements of the constructor you'd run into the same issues.

Then there are partial methods, and in a lot of ways many of the good object oriented design principles based around dependency management could almost be seen as ways of getting units of work that are more composable, you really have to wonder. Instead of only being able to work on method inputs and outputs, or predefined points where a strategy object/method is employed you have a bit more flexibility.

Add to that companion objects and all of a sudden factories and a whole lot more become far more trivial.

Given that's the case, you really can get away from having to use interfaces everywhere, and with more powerful generics system, some of what gets done with interfaces gets sucked up there.

Generally looking at Scala code it tends to be rather decomposed, and interfaces don't seem to be the main tool in that.

Answer 2

That's a really thought-provoking question.

It doesn't seem to be a common pattern (at least in the Scala I've seen), but I can't off the top of my head think of a good argument against it if that's what you really want to do.

On the other hand, I don't think I'd do it that way (I'd refactor when I had an actual need, rather than building in such "flexibility" for a hypothetical future that might never come). But the best argument against it I can think of is the analogy to avoiding needless indirection (don't use a pointer to a pointer to a pointer to an integer when all you need is an integer), and that's not very compelling.