13

Possible Duplicate:
Why are singleton objects more object orientated?

Why does Scala have language support for the Singleton anti-pattern? If Scala had inherited the static keyword from Java, what legitimate use cases of the object keyword would be left?

Community
  • 1
  • 1
fredoverflow
  • 256,549
  • 94
  • 388
  • 662
  • I wouldn't say singletons are really bad, it's just that they're misused most of the time and become an anti-pattern. That being said, I've never encountered a situation where a static class doesn't work better. – Robert Rouhani Aug 01 '12 at 09:01
  • Static declarations are essentially just the global variables which are even more widely decried than singletons. Singletons can be misused in much the same way, but at least they can be inherited from, hidden behind interfaces, and offer the potential for testability and decoupling of code which static calls do not. – David Burton Nov 22 '12 at 16:20
  • 1
    There are appropriate places to use singletons. For example, if the system has a resource which can only be safely interacted with by one caller at a time, it may make sense to use a Singleton wrapper for that resource. For example, a STDOUT stream object could arguably be modeled as a singleton. – Rich Remer Jul 14 '14 at 21:22

4 Answers4

11

There is an up-front difference at least, in that an object in Scala actually is an object (i.e. an instance), rather than in Java where it's just methods called on the class itself.

This means that it avoids one of the major complaints about singletons - since it is an instance, it can be passed around and wired into methods, and so can be swapped out for other implementations during tests, etc. If anything it's syntactic sugar for the recommended alternative to singletons - having a class with a getInstance() method returning the default, single instance.

That said, I consider that the Singleton anti-pattern is more about design than it is language features. If you structure your code base such that some monolithic dependency is implicitly wired throughout most of the classes, then you're going to have issues changing it - regardless of the language features.

There are legitimate use cases for objects in Scala (e.g. using case objects for messages to Actors, or having several of them extend a sealed trait as an alternative to enums). The language feature can be abused, but to my mind it's less abusable than Java's static, and more useful.

Community
  • 1
  • 1
Andrzej Doyle
  • 102,507
  • 33
  • 189
  • 228
6

Singletons without state aren't that bad. I see objects (in scala) as modules to put functions (behaviour) in.

Jan
  • 1,767
  • 16
  • 18
  • And if some other class B has method C which uses one of these Singletons and you want to unit test method C in isolation with mocks instead of real Singletons methods, then what do you do? – MaxNevermind Jun 14 '17 at 18:25
  • As the singleton has no state, I simply use it in the tests. – Jan Apr 28 '22 at 08:41
3

If you use an object to hold state, that's a case where singletons are a disaster, because there may not be a way to clear it up and that's one of the prime examples of singletons being an anti-pattern. An object without mutable state and with pure functions is much less prone to causing pain in this respect, here's an example:

object StringSerializer extends Serializer[String] {
  // Implementation goes here.
}

In this case there's no need to new up an instance of the Serializer, which makes for simpler code and likely better performance.

Sean Parsons
  • 2,832
  • 21
  • 17
2

For example type classes. The difference between static classes and singletons is, that singletons are objects and can be passed around as parameters. This code for example could not be built with static classes:

trait TypeClass[A] {
  def method(x: A): A
}

implicit object IntTypeClass extends TypeClass[Int] {
  def method(x: Int) = x*x
}

def foo[A](x: A)(implicit tc: TypeClass[A]) = tc.method(x)

scala> foo(2)
res0: Int = 4
drexin
  • 24,225
  • 4
  • 67
  • 81