The prototype class lets you use many instances of a specific class, without copying objects to different variables.

The most customizable option for programmatic creation is the Prototype pattern. This pattern consists in choosing an already existent object, with a clone() operation available, as the base for creating new objects of the same kind.

In the Prototype Pattern we create one standard object for each class, and clone that object to create new instances.

The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the “service locator” which on request returns the information necessary to perform a certain task.

It allows overrides or renamed physical resources .

The “service locator” can act as a simple run-time linker. This allows code to be added at run-time without re-compiling the application, and in some cases without having to even restart it.

Applications can optimize themselves at run-time by selectively adding and removing items from the service locator. For example, an application can detect that it has a better library for reading JPG images available than the default one, and alter the registry accordingly.

Large sections of a library or application can be completely separated. The only link between them becomes the registry.

The Registry pattern provides a mechanism for storing data globally in a well managed fashion, helping to prevent global meltdown.

The goal of the registry pattern is simply to provide client code with a mechanism which allows you to save and retrieve resources across different points of an application. In general creating a basic registry using an object-oriented approach demands that you build a class containing the methods required to perform the saving/retrieval tasks.

A registry is a container for shared objects. In the really basic version, you could use an array. As such, the variable $GLOBALS could be called a registry.

A decorator class allows you to add more capacity to an existing class while leaving the original class untouched. It has certain advantages over inheritance.

It can be used when you needed to construct a “bridging” class that was capable of extending the operability and functionality of a base class, but without having to introduce changes in its original structure

Indeed, one of the most appealing aspects of the decorator design pattern is the ease with which you can use a class of different type to extend the capabilities of another. Of course, this isn’t always the best course of action to take, simply because it can be much easier to modify the original class by using inheritance, but there are situations where a decorator class can find its place inside an application.

In this pattern, algorithms are extracted from complex classes so they can be replaced easily

The strategy design pattern can be very useful in the context of form validation.

The observer pattern gives you another way to avoid tight coupling between components. This pattern is simple: One object makes itself observable by adding a method that allows another object, the observer, to register itself. When the observable object changes, it sends a message to the registered observers. What those observers do with that information isn’t relevant or important to the observable object. The result is a way for objects to talk with each other without necessarily understanding why.

It’s also known as the Subscribe/Publish Pattern

The Observer pattern is perhaps most often encountered in traditional graphical user interface desktop applications. It is an excellent way of ensuring that disparate display components reflect changes at a system’s core. As we shall see, though, it remains a powerful technique in a Web-oriented environment.

An object is a singleton if the application can include one and only one of that object at a time.

The Singleton Pattern is one of the GoF (Gang of Four) Patterns. This particular pattern provides a method for limiting the number of instances of an object to just one. It’s an easy pattern to grasp once you get past the strange syntax used.

It ensure a class has only one instance and provide a global point of access to it.

It achieves this by only creating a new instance the first time it is referenced, and thereafter it simply returns the handle to the existing instance.

The factory pattern is a class that has some methods that create objects for you. Instead of using new directly, you use the factory class to create objects. That way, if you want to change the types of objects created, you can change just the factory. All the code that uses the factory changes automatically.

It refers to the newly created object through a common interface

When developing larger, more complex systems though, object creation can become difficult. There are situations where different objects may need to be created based on different conditions or based on the context of the object creating it. Creating objects of concrete types explicitly in code can make these situations a nightmare when it comes time to make revisions and additions. When a new class is introduced, you get to follow a trail of code and commence the hours of debugging that will inevitably follow such an endeavor.

The Factory Method pattern defines an interface for object creation but defers the actual instantiation to subclasses.