Advertisement
Creative Coding

Design Patterns in WordPress: The Singleton Pattern

by

Throughout this series, we're taking a look at the significance of design patterns and the roles that they play in WordPress development.

In the first post in the series, we took a high-level survey and even reviewed the Observer Pattern to see how it's possible to register various functions or objects with certain events that occur within the lifecycle of an application.

In this post, where's going to take a look at the Singleton Pattern.

Specifically, we're going to take a look at the definition of the pattern and how it works, we're going to review a diagram of what the architecture of the pattern looks like, we'll cover some sample code for the pattern, and then we'll discuss the advantages of the pattern as it relates to WordPress development.


The Singleton Pattern

Wikipedia defines the Singleton Pattern as follows:

In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object.

Perhaps a simpler way of explaining the pattern is this: The Singleton Pattern ensures that a class can only have one instance and it provides a single way to retrieve an instance of itself.

So Why Does This Matter in WordPress?

As far as theme development is concerned, I personally don't see much of a use for it unless you're bundling some type of helper class or library with your theme; however, if you're building plugins, then this can be exceptionally useful.

As of now, there are really only a handful of ways to instantiate plugins (excluding widgets - that's another topic) within WordPress:

  • You can instantiate the plugin at the bottom of your plugin file, but this can lead to an orphaned object
  • You can stick the plugin in the PHP $GLOBALS collection, but this can be dangerous as you could trash something that already exists or it's making the collection needlessly larger
  • If you instantiate it with, say, each page load then the data isn't being persisted unless you serialize and hammer the database each time the plugin is instantiated

None of the above are particularly good strategies (although you could make a case that they all work).

However, we care more than just getting something to work, right? We want it to work and we want an elegant solution to the problem. This is where design patterns - more specifically, the Singleton Pattern - come into play.


What It Looks Like

First, let's take a look at a diagram of the Singleton Pattern. Check out the diagram below, then we'll talk about the specifics after the image:

The Singleton Pattern

So here are the key features of the Singleton Pattern:

  • There is a private, static instance variable defined in the attributes that is used to maintain a reference to the class
  • The constructor has been marked as private
  • There is a public static function named get_instance which is used to return an instance of the class

Nothing too complicated, but I think reviewing the code for the Singleton Pattern goes a long way in making it a bit clearer, so let's do that now:

class Foo {

	/*--------------------------------------------*
	 * Attributes
	 *--------------------------------------------*/

	/** Refers to a single instance of this class. */
	private static $instance = null;

	/*--------------------------------------------*
	 * Constructor
	 *--------------------------------------------*/

	/**
	 * Creates or returns an instance of this class.
	 *
	 * @return	Foo	A single instance of this class.
	 */
	public static function get_instance() {

		if ( null == self::$instance ) {
			self::$instance = new self;
		}

		return self::$instance;

	} // end get_instance;

	/**
	 * Initializes the plugin by setting localization, filters, and administration functions.
	 */
	private function __construct() {

	} // end constructor

	/*--------------------------------------------*
	 * Functions
	 *--------------------------------------------*/

} // end class

Foo::get_instance();

Obviously, there's been a lot of code left out of the above class, but the pattern's principles remain.

Notice that we have a private, static instance variable that's used to refer to this class. Specifically, it's set in the get_instance function whereas the constructor has been marked as private.

Typically, when instantiating classes, the constructor is the function that is called whenever we initialize classes; however, in this case, the constructor is marked as private.

So what gives?

Notice that we have a public get_instance function just above the constructor. This function literally checks to see if the static instance variable is null and, if so, creates a new instance of the class (which it can do since it's within the context of the class); otherwise, it returns the current instance.

This is how no more than a single instance of a class is created.

Finally, note that we instantiate the class not with the standard new keyword, but by calling get_instance. Not only that, but we also get future references to the class by using the same method.

So, for example, let's say that you're working in another template and you need to call a function - say bar() - that exists in your plugin. In that case, you'd do something like this:

$foo = Foo::get_instance();
$foo->bar();

Pretty neat, isn't it?


The Advantages of the Singleton Pattern

Despite the fact that we've covered the Singleton Pattern from an architectural and a practical standpoint, we haven't actually talked about the advantages of the pattern.

Generally speaking:

  • The Singleton Pattern prevents other objects or clients from duplicating instances of the class. This makes sure that there's only one copy of the data maintained at any given time. All access to the object is done so by the single instance.
  • We have a wide array of flexibility when it comes to implementation because we can actually impact the instantiation process (though this is a bit out of scope for this particular post).

Perhaps the largest drawback from using the pattern is lack of clarity that the plugin actually uses the pattern. If someone tries to instantiate the class, instantiation will fail because there's no public constructor.

As such, documentation is key.


Conclusion

Whether you've seen them before or this is your first foray into design patterns, the Singleton Pattern is arguably the simplest design pattern there is. It's easy to implement, and it provides a significant source of functionality when implemented correctly especially as it relates to web applications.

In the next post, we'll take a look at another pattern - the Simple Factory Pattern - which is useful when you have a number of classes each of which has a unique purpose and that will be needed based on certain input criteria.

Related Posts
  • Code
    WordPress
    Object-Oriented Programming in WordPress: ClassesWordpress oop
    Classes are the foundation of object-oriented programming. For some, the concept is simple; for others, not so much. In this article, we're going to continue our beginner's series on object-oriented programming by taking a look at the concept of classes and how they lay the foundation for everything we'll use moving forward.Read More…
  • Code
    JavaScript & AJAX
    JavaScript ObjectsCover
    In JavaScript, objects are king: Almost everything is an object or acts like an object. Understand objects and you will understand JavaScript. So let's examine the creation of objects in JavaScript.Read More…
  • Code
    iOS SDK
    Objective-C Succinctly: Methods0e5ds8 preview image@2x
    In this chapter, we'll explore Objective-C methods in much more detail than we have in previous chapters. This includes an in-depth discussion of instance methods, class methods, important built-in methods, inheritance, naming conventions, and common design patterns.Read More…
  • Code
    Creative Coding
    A Look at the WordPress HTTP API: A Practical Example of wp_remote_postDiagram http api
    In the previous article, we reviewed the previous articles regarding GET requests, the native PHP facilities for making requests, and reviewed WordPress wp_remote_post API function along with the arguments that it offers. In this article, we're going to make use of wp_remote_post such that we're actually able to see it in action. Remember that this - like wp_remote_post - is part of the HTTP API of which there are other functions worth reviewing. But, for now, we're going to put wp_remote_post to work. Specifically, we're going to do the following: When the page loads, we're going to submit some information to a custom script The script will examine the information and return it to our page We'll then display the data on the page Sure, it's a bit of a contrived example but it will give us the experience of creating a separate PHP script that can be used for operations triggered by the use of wp_remote_post. Anyway, for the purposes of this example, we are going to use the PHP $_SERVER collection to log when the user has submitted their preference rather than require that they have logged in. Finally, the source code will be made available on GitHub and accessible at the end of this series in the following article. For now however, let's get started with working on the plugin.Read More…
  • Code
    Creative Coding
    A Look at the WordPress HTTP API: A Practical Example of wp_remote_getDiagram http api
    In the last article in this series, we took a look at the PHP functions that are available for making remote requests. Specifically, we reviewed: file_get_contents cURL And we also discussed the WordPress function wp_remote_get. In this article, we're going to put the wp_remote_get to work. This function is part of the HTTP API - to practical use by using it to retrieve the following two things: The number of followers we have on Twitter Our most recent Tweet The nice thing is that we won't need to use any OAuth or authentication mechanisms, and we'll only need to take advantage of Twitter responses and PHP's JSON functionality. So in this article, we're going to take a practical look at how to do exactly this, then we'll end the series reviewing all of the information that wp_remote_get returns so that we'll know how to properly handle it in future work.Read More…
  • Code
    Creative Coding
    Design Patterns in WordPress: The Simple Factory PatternDesign patterns in wordpress
    In this series, we're taking a look at design patterns and how we can leverage them to our advantage when building products on top of WordPress. The nice thing about design patterns is that they aren't explicitly limited to themes or plugins - they are handy in a variety of different scenarios. It's simply a matter of being able to identify which patterns are applicable to certain scenarios.Read More…