Menu
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:
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?
302
Here is one major difference that Scala has from Java: there are no interfaces. There is no interface keyword. Yes, even though Scala is primarily a JVM language and often touted as a "better Java", it doesn't have interfaces.
Like a class, Traits can have methods(both abstract and non-abstract), and fields as its members. Traits are just like interfaces in Java. But they are more powerful than the interface in Java because in the traits we are allowed to implement the members.
An interface is a contract that says “this object is able to do this thing”, whereas a trait is giving the object the ability to do the thing. A trait is essentially a way to “copy and paste” code between classes.
Traits can not implement interfaces. A trait allow both classes to use it for common interface requirement. It supports the use of abstract methods.
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.
92
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.
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
