The singleton pattern is a fairly controversial pattern among certain parts of the development community. Some would even call it an anti-pattern. One of the main reasons for this, is the singleton pattern introduces a global state into our applications. A state that gives the ability to change an object at any point within our application. While the pattern can be controversial, if used correctly the singleton pattern can be very useful.
The title of this post indicates that we are introducing the Singleton pattern as a Protocol Oriented design pattern however you will note that we are using a class (reference type) to implement the pattern rather than a struct (value type). The reason for this is; when we pass an instance of a value type we are passing the value and not a reference to the original instance therefore there isn’t a way to implement the Singleton pattern with a value type. This means that within our protocol-oriented design patterns, the singleton pattern is one that needs to be implemented like we would with object-oriented design patterns.
Problem We Are Trying To Solve
The singleton pattern is used when we need to restrict a class to one and only one instance throughout the life cycle of our application. This is useful when we need one object to coordinate actions across the application.
Our Solution
For our solution we are going to use class constants. With this solution, a single instance of the class is created the first time the class constant is accesses. Once the instance is created, then the class constant will access that instance throughout the life cycle of the application. We will also create a private initializer which will prevent external code from creating additional instances of the class.
The Example
In this example, we have an application that connects to a Bluetooth enabled device. This application will have several pages, like an introduction page, pairing page, settings page and a page to see the data. We will need to maintain the connection to the Bluetooth device as we are moving between pages, even pages that do not directly communicate with the device. The following illustrates the Singleton pattern.
As usual in our design pattern tutorials, we are going to be showing the minimal amount of code necessary to demonstrate the pattern because we want the focus of this post to be on how the singleton design pattern works and not on implementing the example.
The singleton pattern will need to be created using a class (reference type). Let’s look at how we would create the singleton type.
class BluetoothManager {
static let sharedInstance = BluetoothManager()
private init() {}
//Bluetooth specific code
}Within the BluetoothManager class, we created a static constant named shareInstance which contains an instance of the BluetoothManager class. A static constant or variable can be called without create an instance of the class. Since we declared sharedInstance as a static constant, there will only be one instance of this constant throughout the lifecycle of the application thereby creating the singleton pattern.
By declaring the initiator as private, we are ensuring that no code outside of this class can create a separate instance of this class. To properly implement the singleton pattern, it is essential that the initiator is private.
We would use the BluetoothManager type like this anywhere in our code that needs to access the Bluetooth device:
var bluetoothManager = BluetoothManager.sharedInstanceAs I mentioned in the beginning, the singleton pattern can be controversial among some developers and we really should be careful to ensure that we are not using this pattern when we shouldn’t. If we are properly using this pattern, then the Singleton pattern can be very useful for coordinating or maintain a state between views in our application.
