Question

General style question.

As I become better at writing functional code, more of my methods are becoming pure functions. I find that lots of my “classes” (in the loose sense of a container of code) are becoming state free. Therefore I make them objects instead of classes as there is no need to instantiate them.

Now in the Java world, having a class full of “static” methods would seem rather odd, and is generally only used for “helper” classes, like you see with Guava and Commons-* and so on.

So my question is, in the Scala world, is having lots of logic inside “objects” and not “classes” quite normal, or is there another preferred idiom.

Answer 1

As you mention in your title, objects are singleton classes, not classes with static methods as you mention in the text of your question.

And there are a few things that make scala objects better than both static AND singletons in java-world, so it is quite “normal” to use them in scala.

For one thing, unlike static methods, object methods are polymorphic, so you can easily inject objects as dependencies:

scala> trait Quack {def quack="quack"}
defined trait Quack

scala> class Duck extends Quack
defined class Duck

scala> object Quacker extends Quack {override def quack="QUAACK"}
defined module Quacker

// MakeItQuack expects something implementing Quack
scala> def MakeItQuack(q: Quack) = q.quack
MakeItQuack: (q: Quack)java.lang.String

// ...it can be a class
scala> MakeItQuack(new Duck)
res0: java.lang.String = quack

// ...or it can be an object
scala> MakeItQuack(Quacker)
res1: java.lang.String = QUAACK

This makes them usable without tight coupling and without promoting global state (which are two of the issues generally attributed to both static methods and singletons).

Then there’s the fact that they do away with all the boilerplate that makes singletons so ugly and unidiomatic-looking in java. This is an often overlooked point, in my opinion, and part of what makes singletons so frowned upon in java even when they are stateless and not used as global state.

Also, the boilerplate you have to repeat in all java singletons gives the class two responsibilities: ensuring there’s only one instance of itself and doing whatever it’s supposed to do. The fact that scala has a declarative way of specifying that something is a singleton relieves the class and the programmer from breaking the single responsibility principle. In scala you know an object is a singleton and you can just reason about what it does.