The Singleton Pattern

Welcome to the second in a series of posts about anti-patterns in Ruby!


What is a singleton?  A singleton is a single instance of a class, particularly a single instance of a class - to be a singleton, a class must have the property of only being able to be created once (note that a singleton could not be created yet, so a singleton doesn't have the property of necessarily existing).

Why use a Singleton pattern?

* You have a single resource that you need to model - for instance, a log file.

* You need quick access to a particular resource throughout your system and don't want to have to remake it every time.

* Having more than one of a resource might be dangerous in your system - for example, if you're designing hardware related to a physical system, it may cause serious problems if you have multiple instances of an object floating around and different parts of the software are making calculations from different representations of a real-world machine part.

* ...other reasons that you need only a single instance of a class.

But you better have a darn good reason if you're going down this path because singletons are generally considered an anti-pattern and they give off a bad code smell.

Singletons make code less flexible, which in and of itself is enough to generally avoid them - code needs to be flexible because, in addition to the seeming inexterminability of some bug somewhere, the computer ecosystem that any particular piece of code exists in almost always changes.  Operating systems change, hardware changes, databases change, user needs change, everything about the web changes...and if you want your code to continue to be useful, you should expect that you need to change it too, especially in ways that you don't think you'll need to.

Sure, there's plenty of COBOL and the like running deep within the electronic hearts of our most important institutions, but even those old COBOL programs sometimes have to be picked up, dusted off, and given a big spray from a can of Raid - remember the Y2K bug?  You might not be able to think of a reason you need more than one instance of your class now, but that could change.

But there are other reasons singletons can be bad:

* Singletons can be hard to test, since it can be a pain to get them into the state you need them to be for your test - since a singleton can be accessed from anywhere and it's the only one, it could be altered by some other area of your code.  Singletons keep their state as long as your program is running, so the order of testing can make a difference as to what state a singleton is in.

* Singletons are often put into code as a way to avoid having to pass information around; though having a single reference can be easier, it's also more dangerous for the same reasons as above: the singleton's state could, unbeknownst to you, unintentionally be impacted by other areas of your code when you need to reference it.

* Singletons with dependencies on each other can cause tricky situations if you need to remove one of them from your code.

You may notice that these sound a lot like the problems with global variables.  They are.  In fact, a lot of folks basically equate singletons with global variables or global state.  This isn't a totally fair comparison - singletons can have additional logic and other capabilities that global variables don't have.  But there's enough similarity there to make you squint.  And, like global variables, when you're tempted to use a singleton, you should take pause before doing anything rash.

Okay, enough scare talk.  We want to make a singleton.  How do you do that?  In Ruby, it's pretty simple: use the Singleton module. Ruby comes pre-loaded with the ability to make singletons! How easy!

require 'singleton'

class FirstSingleton
include Singleton
end

That's all you need to do.  If you try to create an instance of FirstSingleton,

require 'singleton'

class FirstSingleton
include Singleton
end

FirstSingleton.new

you get an error message:


But if you just try to see your singleton instance,

require 'singleton'

class FirstSingleton
include Singleton
end

puts FirstSingleton.instance

 that's no problem:

If you try to create more than one instance, you still only get one:

require 'singleton'

class FirstSingleton
include Singleton
end

x = FirstSingleton.instance
y = FirstSingleton.instance
puts x == y
# => true





Comments

Post a Comment

Popular posts from this blog

The Sorting Hat

Image
Here's a lesson about the difference between theory and practical applications. Everyone knows about  bubble Sort  and  merge Sort  - they're probably the first two sorting algorithms you learned.  Everyone also knows that (1) bubble sort sucks and (2) this is due to the fact that its average time complexity is O(n^2), aka the worst time complexity.  It even generally performs worse than things like insertion sort and  selection sort , the "a D- is still a passing grade" of sorting algorithms. While all these things are true, there's a more important truth: always test your code. While reading  The Imposter's Handbook by Rob Conery  the other day and flipping through the comparison sort algorithms he provides, I decided, Why not actually test out this code?   And, the  speed test demon  that I am, my test involved sorting out his [23,4,42,15,16,8] array one million times with bubble sort and with merge sort, and I got this res...
Read more

Kadane's Algorithm

Imagine it is 1977.  You do not have a degree in computer science.  You have not spent months grinding leetcode.  You are given a algorithm problem that a decorated mathematician has already created what looks like an optimal solution. And then in less than a minute you come up with a better answer. You are  Jay Kadane , and the problem that you have solved is the maximum subarray problem. The maximum subarray problem gives you an array of numbers and asks you to pick out the subarray with the largest sum.  The problem is trivial if all the numbers are positive: [ 1 , 5 , 1 , 3 , 2 ] <- the largest subarray is obviously the entire array But what if you've got some negative numbers thrown in there? [ 1 , 5 , -1, 3 , - 2 ] <- sure, you don't want the negatives. But isn't taking the -1 worth the +3? A brute-force solution materializes pretty easily: just create every subarray and find the biggest sum: [ 1 ] = 1 [ 1 , 5 ] = 6 [ 1 , 5 , - 1 ] = 5 ...
Read more

Loose Equality, the Null Operator, and Other Oddities

 Here's a fun bit of code to run: console . log ( '0.5' == 0.5 ) //evaluates to true console . log ( '0.5' === 0.5 ) //evaluates to false The first equality statement is what's known in JavaScript as "abstract equality comparison", which people usually refer to as "loose equality."  Loose equality compares objects only after doing a type conversion - so even though '0.5' is a string and 0.5 is a number, JavaScript sort of jams them together and says "sure, good enough."  It's weird, but convenient sometimes when dealing with data that's really (in an abstract sense) numbers but could come through the pipes as either a number or a string. People have written surprisingly long algorithms to precisely define what  abstract equality  and  strict equality (aka, normal equality)  mean in JavaScript and other languages that adhere to the ECMAScript standards.  But for our regular usage, things that are to people the same ...
Read more