Servage Magazine

Information about YOUR hosting company – where we give you a clear picture of what we think and do!

Common design-patterns explained

Tuesday, May 2nd, 2017 by Servage

design-patternsDesign patterns are used in software design to overcome common problems. For instance, what if you need a class that handles all database connections and you want to be able to create only one instance of that class? This is where design patterns are handy. They help you solve common design problems with universal solutions that you can also find in other applications.

Singleton Pattern

Let’s start with a simple pattern. Singleton is a design pattern whose purpose is to keep only one instance of a class. This way, there is no need to instantiate a new object every time you call a method.

A singleton class can be created by making the constructor of the class private. This prevents you to create a new instance of the object using the new keyword, such as $object Object = new Object(). Instead of doing this to get a reference to the object, you implement a getInstance() method and a private static variable to hold a reference to the instance, such as private static $instance. Calling the getInstance() method returns this instance: return static::$instance.

Dependency Injection

The singleton pattern is sometimes criticised for being difficult to test. The dependency injection pattern is similar to singletons and can be found in many modern frameworks in place of singletons. Dependency injection means that the dependencies of a class are “injected” to the class that needs them. A dependency is something the class needs to do its job. In most cases it’s an instance of some other class.

A class usually receives its dependencies as a parameter to its constructor like this: public function __construct(Configuration $config) {} where $config is the injected dependency. Frameworks like Laravel heavily utilize dependency injection, allowing you to easily inject and make almost any class available in your controller functions.

Observer Pattern

Instead of checking whether an object’s state has changed every X seconds, you can use the observer pattern. In this pattern, an observer object listens to a subject for changes. When the state of the subject changes, it will automatically notify all observers that are interested in state changes of the subject. The observer pattern can be found in client-server applications, such as instant messaging applications. The pattern and similar approaches can also be found in many front-end applications, such as those built with Angular or React.

Factory Pattern

Typically when you want to create a new object, you use the new keyword. However, when using the factory pattern, you pass the arguments to a factory class instead. If the factory is a static factory, it has a static function that can be called to create a new method, for example: UserFactory::create(‘John’, ‘Doe’). This returns the newly created object.

This was a simple example, but sometimes creating new objects is not a matter of a one-line method call. For example, if you are using the Guzzle HTTP client in many different files in your project and want to configure a base URL, default request timeout and other settings, you could do these inside a factory instead of setting them up every time you need Guzzle.

Common design-patterns explained, 4.0 out of 5 based on 4 ratings
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet (leave a comment)

You are welcome to initiate a conversation about this blog entry.

Leave a comment

You must be logged in to post a comment.