Skip to content

JREAM/design-patterns

Repository files navigation

Design Patterns

These are design patterns in their simplest form. Currently the bold items are ones I have examples for.

More will come later on.

  • abstract_factory - Creates families of related objects.
  • adapter - Lets classes work together that don't have compatible interfaces.
  • builder - Separate construction of complex objects.
  • command - Add parameters to clients with different requets, and undoable operations.
  • composite - Composer objects in a tree structure and handle them individually.
  • decorator - Add more responsibility to objects dynamically.
  • dependency_injection - Easily share "services" across a platform. (DI, aka IoC/Inversion of Control)
  • facade - Makes subsystems easier to use.
  • factory - Creates a single subclass with that are similar.
  • front_controller - Most MVC's and web applications use this pattern.
  • iterator - Access elements of an aggregate object without knowing whats under the hood.
  • mediator - Decouples Objects and Coordinates them together with a middle man (Events, Notifications)
  • memento - No encapsulation, allows you to change an objects internal state
  • multi_inherit - Extend a base class and act as if we can extend other classes for added functionality
  • observer - (aka Publish/Subscribe) One to Many Dependency to notify that an object has changed.
  • prototype - Create new object by cloning from a skeleton of an object.
  • proxy - Placeholder for another object to acccess it.
  • singleton - Only allow one instance for an objects lifespan.
  • state - Alter an object when it changes state.
  • template method - Subclasses can redfine certain steps of without messing up the main structure.
  • visitor - New operations defined without change classes or elements it operates on.

About the Patterns

This is made to understand patterns as simple as possible. So here are a few things to know:

  • Notes are provided in the class.

  • I will not be using namespaces to keep it simple.

  • At the bottom of the class contain examples.

  • The name of the pattern is the name of the class.

  • Classes not requiring Abstract Classes and Interfaces are not included to keep it simple.

  • You would generally do this:

    • In most cases, change the name of the class(es).
    • Put your classes in separate files.

    --

    (c) 2016 Jesse Boyer | MIT License

About

Simple examples of Design Patterns with PHP Examples

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages