The Most OO of Them All

“As mentioned in Chapter 1, one way in which Scala is more object-oriented
than Java is that classes in Scala cannot have static members.”

So begins the Singleton objects section of my Scala book, incidentally managing to sound not a little smug.

Presumably, the reasoning is that if you eliminate static variables — which are the least object-oriented part of the whole OO idea, as they’re not tied to instances — you’ll have to put them somewhere to make up for it.

It seems like Scala’s way around this is the companion class, a class-like object that needs to be in the same file.

Imagine you had an incredibly simple class that stored a static member called MAXEvery instance of that class could be initialized by passing in some random int, and a method called isMoreThanMax checked against MAX. 

public class StaticallyDone {
	protected static int max = 5; 
	private int num; 
	StaticallyDone(int num) { 
		this.num = num; 
	public boolean isMoreThanMax() { 
		return this.num > max; 
	public int getThisNum() { 
		return this.num; 

Now say you wanted to get rid of this static MAX thing (okay, the code doesn’t make any sense, but this is a toy example). One way to do it — not a great way, just a way — is to move MAX out to something else, and let the other thing deal with the class.

    public boolean isMoreThanMax(StaticallyDone passed) {
        return passed.getThisNum() > max; 

Not fantastic programmatically, but merely an analogue.

So this is how Scala deals with the way statically typed objects can be “translated” over from Java — to move them out to a whole entire class by themselves, abstracting out the static part.

In this example, there’s a ChecksumAccumulator class that calculates the checksum of some string. You can save yourself some trouble if you also create a cache in that class, against which all new strings can be checked. If the string has been seen before, you’ll have saved yourself some computation time.

Except that the cache needs to be class-wide; what would be the point of every instance having its own cache? (Forget that this entire construct is questionable — we should’ve created a single instance of this entire thing and injected or singleton-d it or something)

So now you have this static variable for the cache … which Scala doesn’t allow.

Enter the companion object. This object stores a private, mutable cache, and exposes a public function for calculating the checksum of any object — except it calls the ChecksumAccumulator class-for-real and makes it do the calculation. All the object does is store this static cache.

When I first met the companion object, I thought yet another strange Scala affectation — no wonder everyone acts like they belong to a secret cabal, the weirdos. Except that the more I’ve come to learn about things like public/private variables and the companion objects, the more I seem to see the reasoning behind them.

Incidentally, for my 0.75 readers out there who might be interested/knowledgeable in the subject, comments/corrections/suggestions/awful Scala puns are all welcome.


2 thoughts on “The Most OO of Them All

  1. HEY! I’m slightly more than 0.75 of a human. And if I carry sitting in a chair all day like this, I’m going to become 1.75 of a human soon enough 😦

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s