(For more resources related to this topic, see here.)

Design patterns are ways to solve a problem and the way to get your intended result in the best possible manner. So, design patterns are not only ways to create a large and robust system, but they also provide great architectures in a friendly manner.

In software engineering, a design pattern is a general repeatable and optimized solution to a commonly occurring problem within a given context in software design. It is a description or template for how to solve a problem, and the solution can be used in different instances. The following are some of the benefits of using design patterns:

• Maintenance
• Documentation
• Readability
• Ease in finding appropriate objects
• Ease in determining object granularity
• Ease in specifying object interfaces
• Ease in implementing even for large software projects
• Implements the code reusability concept

If you are not familiar with design patterns, the best way to begin understanding is observing the solutions we use for commonly occurring, everyday life problems.

Let’s take a look at the following image:

Many different types of power plugs exist in the world. So, we need a solution that is reusable, optimized, and cheaper than buying a new device for different power plug types. In simple words, we need an adapter. Have a look at the following image of an adapter:

In this case, an adapter is the best solution that’s reusable, optimized, and cheap. But an adapter does not provide us with a solution when our car’s wheel blows out.

In object-oriented languages, we the programmers use the objects to do whatever we want to have the outcome we desire. Hence, we have many types of objects, situations, and problems. That means we need more than just one approach to solving different kinds of problems.

Elements of design patterns

The following are the elements of design patterns:

• Name: This is a handle we can use to describe the problem
• Problem: This describes when to apply the pattern
• Solution: This describes the elements, relationships, responsibilities, and collaborations, in a way that we follow to solve a problem
• Consequences: This details the results and trade-offs of applying the pattern

Classification of design patterns

Design patterns are generally divided into three fundamental groups:

• Creational patterns
• Structural patterns
• Behavioral patterns

Let’s examine these in the following subsections.

Creational patterns

Creational patterns are a subset of design patterns in the field of software development; they serve to create objects. They decouple the design of an object from its representation. Object creation is encapsulated and outsourced (for example, in a factory) to keep the context of object creation independent from concrete implementation. This is in accordance with the rule: “Program on the interface, not the implementation.”

Some of the features of creational patterns are as follows:

• Generic instantiation: This allows objects to be created in a system without having to identify a specific class type in code (Abstract Factory and Factory pattern)
• Simplicity: Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object (Builder (Manager) and Prototype pattern)
• Creation constraints: Creational patterns can put bounds on who can create objects, how they are created, and when they are created

The following patterns are called creational patterns:

• The Abstract Factory pattern
• The Factory pattern
• The Builder (Manager) pattern
• The Prototype pattern
• The Singleton pattern

Structural patterns

In software engineering, design patterns structure patterns facilitate easy ways for communications between various entities.

Some of the examples of structures of the samples are as follows:

• Composition: This composes objects into a tree structure (whole hierarchies). Composition allows customers to be uniformly treated as individual objects according to their composition.
• Decorator: This dynamically adds options to an object. A Decorator is a flexible alternative embodiment to extend functionality.
• Flies: This is a share of small objects (objects without conditions) that prevent overproduction.
• Adapter: This converts the interface of a class into another interface that the clients expect. Adapter lets those classes work together that would normally not be able to because of the different interfaces.
• Facade: This provides a unified interface meeting the various interfaces of a subsystem. Facade defines a higher-level interface to the subsystem, which is easier to use.
• Proxy: This implements the replacement (surrogate) of another object that controls access to the original object.
• Bridge: This separates an abstraction from its implementation, which can then be independently altered.

Behavioral patterns

Behavioral patterns are all about a class’ objects’ communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects. The following is a list of the behavioral patterns:

• Chain of Responsibility pattern
• Command pattern
• Interpreter pattern
• Iterator pattern
• Mediator pattern
• Memento pattern
• Observer pattern
• State pattern
• Strategy pattern
• Template pattern
• Visitor pattern

If you want to check out the usage of some patterns in the Laravel core, have a look at the following list:

• The Builder (Manager) pattern: IlluminateAuthAuthManager and IlluminateSessionSessionManager
• The Factory pattern: IlluminateDatabaseDatabaseManager and IlluminateValidationFactory
• The Repository pattern: IlluminateConfigRepository and IlluminateCacheRepository
• The Strategy pattern: IIlluminateCacheStoreInterface and IlluminateConfigLoaderInterface
• The Provider pattern: IIlluminateAuthAuthServiceProvider and IlluminateHashHashServiceProvider

Summary

In this article, we have explained the fundamentals of design patterns. We’ve also introduced some design patterns that are used in the Laravel Framework.

Resources for Article:

Further resources on this subject:

• Laravel 4 – Creating a Simple CRUD Application in Hours [article]
• Your First Application [article]
• Creating and Using Composer Packages [article]