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.