Home > Backend Development > PHP Tutorial > Singleton pattern: designed for efficiency

Singleton pattern: designed for efficiency

PHPz
Release: 2023-08-31 13:54:01
Original
1012 people have browsed it

Singleton pattern: designed for efficiency

In this article, you will learn how to implement the Singleton design pattern, and why and when to use this pattern in your applications. As the name "Singleton" suggests, this method allows us to create a single object of a class.

Let’s see what Wikipedia has to say about this design pattern:

The singleton pattern is a design pattern that limits the instantiation of a class to one object. This is useful when only one object is needed to coordinate the operation of the entire system.

As mentioned in the definition above, when we want to ensure that any class needs to create one and only one object, then we should implement the Singleton pattern for that class.

p>

You may ask why we should implement a class that allows us to create only one object of it. I would say that we can apply this design pattern in many use cases. These include: configuration classes, session classes, database classes, etc.

In this article I will take the database class as an example. First, we'll look at what problems can arise if the singleton pattern is not implemented for such a class.

question

Imagine a very simple database connection class, once we create an object of this class, it creates a connection to the database.

class database {
    
	private $dbName = null, $dbHost = null, $dbPass = null, $dbUser = null;
	
	public function __construct($dbDetails = array()) {
		
		$this->dbName = $dbDetails['db_name'];
		$this->dbHost = $dbDetails['db_host'];
		$this->dbUser = $dbDetails['db_user'];
		$this->dbPass = $dbDetails['db_pass'];

		$this->dbh = new PDO('mysql:host='.$this->dbHost.';dbname='.$this->dbName, $this->dbUser, $this->dbPass);
		
	}
	
}
Copy after login

In the above code example, you can see that every time an object of this class is created, it establishes a connection with the database. So if a developer creates objects of this class in multiple places, imagine the number of (same) database connections it will create with the database server.

Thus, developers unknowingly make mistakes that have a huge impact on the speed of the database and application server. Let us see the same thing by creating different objects of this class.

$dbDetails = array(
    	'db_name' => 'designpatterns',
		'db_host' => 'localhost',
		'db_user' => 'root',
		'db_pass' => 'mysqldba'
);

$db1 = new database($dbDetails);
var_dump($db1);
$db2 = new database($dbDetails);
var_dump($db2);
$db3 = new database($dbDetails);
var_dump($db3);
$db4 = new database($dbDetails);
var_dump($db4);

// Output
object(database)[1]
  private 'dbName' => string 'designpatterns' (length=14)
  private 'dbHost' => string 'localhost' (length=9)
  private 'dbPass' => string 'mysqldba' (length=8)
  private 'dbUser' => string 'root' (length=4)
  public 'dbh' => object(PDO)[2]
object(database)[3]
  private 'dbName' => string 'designpatterns' (length=14)
  private 'dbHost' => string 'localhost' (length=9)
  private 'dbPass' => string 'mysqldba' (length=8)
  private 'dbUser' => string 'root' (length=4)
  public 'dbh' => object(PDO)[4]
object(database)[5]
  private 'dbName' => string 'designpatterns' (length=14)
  private 'dbHost' => string 'localhost' (length=9)
  private 'dbPass' => string 'mysqldba' (length=8)
  private 'dbUser' => string 'root' (length=4)
  public 'dbh' => object(PDO)[6]
object(database)[7]
  private 'dbName' => string 'designpatterns' (length=14)
  private 'dbHost' => string 'localhost' (length=9)
  private 'dbPass' => string 'mysqldba' (length=8)
  private 'dbUser' => string 'root' (length=4)
  public 'dbh' => object(PDO)[8]
Copy after login

If you see the output and output of the above code, you can see that each object is assigned a new resource ID, so all objects are brand new references, so it also allocates separate memory. In this way, our application will unknowingly occupy resources that are not actually needed.

solution

How developers use our underlying framework is beyond our control. Once the code review process happens, it's under our control, but we can't always stand behind them during development.

To overcome this situation, we should make it impossible for our base class to create multiple objects of a class; instead, it will give an already created object (if any). In this case, we should consider developing a singleton pattern for our base class.

In implementing this pattern, our goal is to allow objects of one class to be created at one time and only. Please allow me to add the class code below and then we will go through each part of the class in detail.

class database {
    
	private $dbName = null, $dbHost = null, $dbPass = null, $dbUser = null;
	private static $instance = null;
	
	private function __construct($dbDetails = array()) {
		
		// Please note that this is Private Constructor
		
		$this->dbName = $dbDetails['db_name'];
		$this->dbHost = $dbDetails['db_host'];
		$this->dbUser = $dbDetails['db_user'];
		$this->dbPass = $dbDetails['db_pass'];

		// Your Code here to connect to database //
		$this->dbh = new PDO('mysql:host='.$this->dbHost.';dbname='.$this->dbName, $this->dbUser, $this->dbPass);
	}
	
	public static function connect($dbDetails = array()) {
		
		// Check if instance is already exists 		
		if(self::$instance == null) {
			self::$instance = new database($dbDetails);
		}
		
		return self::$instance;
		
	}
	
	private function __clone() {
		// Stopping Clonning of Object
	}
	
	private function __wakeup() {
		// Stopping unserialize of object
	}
	
}
Copy after login

There is little indication that the above class is a Singleton class. First is the private constructor, which prevents the creation of objects using the new keyword. Another indication is a static member variable that holds a reference to the created object.

$dbDetails = array(
    	'db_name' => 'designpatterns',
		'db_host' => 'localhost',
		'db_user' => 'root',
		'db_pass' => 'mysqldba'
);

$db1 = database::connect($dbDetails);
var_dump($db1);
$db2 = database::connect($dbDetails);
var_dump($db2);
$db3 = database::connect($dbDetails);
var_dump($db3);
$db4 = database::connect($dbDetails);
var_dump($db4);

// Output

object(database)[1]
  private 'dbName' => string 'designpatterns' (length=14)
  private 'dbHost' => string 'localhost' (length=9)
  private 'dbPass' => string 'mysqldba' (length=8)
  private 'dbUser' => string 'root' (length=4)
  public 'dbh' => object(PDO)[2]
object(database)[1]
  private 'dbName' => string 'designpatterns' (length=14)
  private 'dbHost' => string 'localhost' (length=9)
  private 'dbPass' => string 'mysqldba' (length=8)
  private 'dbUser' => string 'root' (length=4)
  public 'dbh' => object(PDO)[2]
object(database)[1]
  private 'dbName' => string 'designpatterns' (length=14)
  private 'dbHost' => string 'localhost' (length=9)
  private 'dbPass' => string 'mysqldba' (length=8)
  private 'dbUser' => string 'root' (length=4)
  public 'dbh' => object(PDO)[2]
object(database)[1]
  private 'dbName' => string 'designpatterns' (length=14)
  private 'dbHost' => string 'localhost' (length=9)
  private 'dbPass' => string 'mysqldba' (length=8)
  private 'dbUser' => string 'root' (length=4)
  public 'dbh' => object(PDO)[2]
Copy after login

If you compare the output of both parts, you will see that in the output of singleton mode, the object resource ID is the same for all different objects. But this is not the case when not using design patterns.

Singleton as anti-pattern

This design pattern is also called an anti-pattern for various reasons, which I will mention below:

  1. Since it controls the quality of its own creation and life cycle, it violates the Single Responsibility Principle.
  2. It introduces global state into your application. I would say global state is very bad because any code can change its value. Therefore, it is difficult to find which part of the code has made the global variables of the current stage during debugging.

  3. If you are doing unit testing, singletons are generally a bad idea, and not doing unit testing is generally a bad idea.

in conclusion

I tried my best to explain the singleton design pattern that is widely discussed on the Internet. I hope this article was helpful to you. We've covered two aspects of this pattern, design patterns and anti-patterns.

Please post your comments, suggestions and/or questions below and I will respond as soon as possible. You can also contact me on Twitter @XpertDevelopers or email me directly.

The above is the detailed content of Singleton pattern: designed for efficiency. For more information, please follow other related articles on the PHP Chinese website!

source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template