CoffeeScript one-piece mode

One-piece mode

Problem

Many times you want one, and just an instance of a class. F or example, you might need a class that creates server resources, and you want to ensure that you can control those resources with an object. Be careful when using this, however, because one-piece patterns can be easily misused to simulate unnecessary global variables.

Solution

Public classes contain only methods for getting one instance. The instance is saved in a closure of the public object and always has a return value.

This works because CoffeeScript allows you to define executable states in a class's declaration. H owever, because most CoffeeScript compiles into an IIFE package, if this works for you, you don't need to place a private class in the declaration of the class. Later content may be useful for developing modular code, such as CommonJS (Node.js) or .js (see example discussion).

class Singleton
  # You can add statements inside the class definition
  # which helps establish private scope (due to closures)
  # instance is defined as null to force correct scope
  instance = null
  # Create a private class that we can initialize however
  # defined inside this scope to force the use of the
  # singleton class.
  class PrivateClass
    constructor: (@message) ->
    echo: -> @message
  # This is a static method used to either retrieve the
  # instance or create a new one.
  @get: (message) ->
    instance ?= new PrivateClass(message)

a = Singleton.get "Hello A"
a.echo() # => "Hello A"

b = Singleton.get "Hello B"
b.echo() # => "Hello A"

Singleton.instance # => undefined
a.instance # => undefined
Singleton.PrivateClass # => undefined

Discuss

From the example above, we can see how all instances are output from the same Singleton class. A s you can also see, neither the private class nor the instance variables are accessible outside singleton class. T he essence of Singleton class is to provide a static method to get an instance that returns only one private class. It also hides private classes from the outside world, so you can't create your own private classes.

The idea of hiding or making private classes work internally is more preferred. E specially since the default CoffeeScript encapsulates the compiled code in your own IIFE (closed package), you can define classes without fear of being accessed outside the file. I n this example, it is noted that the commonly used module export features are used to emphasize the publicly accessible parts of the module. (See a more in-depth discussion of this understanding in Export to Global Namespace.)

root = exports ? this

# Create a private class that we can initialize however
# defined inside the wrapper scope.
class ProtectedClass
  constructor: (@message) ->
  echo: -> @message

class Singleton
  # You can add statements inside the class definition
  # which helps establish private scope (due to closures)
  # instance is defined as null to force correct scope
  instance = null
  # This is a static method used to either retrieve the
  # instance or create a new one.
  @get: (message) ->
    instance ?= new ProtectedClass(message)

# Export Singleton as a module
root.Singleton = Singleton

We can note that coffeescript is so simple to implement this design pattern. To better refer to and discuss the implementation of JavaScript, see the JavaScript design patterns that beginners must have.