I’ve written a Scala trait, named Cache[A,B], to provide a caching API. The Cache has the following methods, asyncGet(), asyncPut(), asyncPutIfAbsent(), asyncRemove().
I’m going to have a few static methods, such as getOrElseUpdate(key: A)(op: => B). I don’t want methods like this as abstract defs in the Cache trait because I don’t want each Cache implementation to have to provide an implementation for it, when it can be written once using the async*() methods.
In looking at Google Guava and parts of the Java library, they place public static functions in a class that is the plural of the interface name, so “Caches” would be the name I would use.
I like this naming scheme actually, even though I could use a Cache companion object. In looking at much of my code, many of my companion objects contain private val’s or def’s, so users of my API then need to look through the companion object to see what they can use from there, or anything for that matter.
By having a object named “Caches” is consistent with Java and also makes it clear that there’s only public functions in there. I’m leaning towards using “object Caches” instead of “object Cache”.
So what do people think?
Scala’s traits are not just a different name for Java’s interfaces. They may have concrete (implemented) members, both values (val and var) and methods. So if there’s a unified / generalized / shared implementation of a method, it can be placed in a trait and need not be replicated or factored into a separate class.