Design Patterns and Principles

A Better Way to Design Your Software

What Vs Why

A general repeatable solution to a commonly occurring problem in software design

Providing tested, proven development paradigms

Common Problem, Well known Proven solution

Reduce Complexity

Does not need to start from scratch

Widely used and thus reduce the technical risk

Highly flexible and language independent (but OOP)

Any Drawbacks...

Patterns do not lead to direct code reuse.

Complex in nature

Teams may suffer from patterns overload.

 Deceptively simple

Everything has some

Besides these drawbacks definitely it's outcome is much more fruitful 

Singleton Pattern

A class of which only a single instance can exist in one Request Life cycle

<?php
class Singleton
{
    /**
     * Returns the *Singleton* instance of this class.
     * @staticvar Singleton $instance The 
     * *Singleton* instances of this class.
     * @return Singleton The *Singleton* instance.
     */
    public static function getInstance()
    {
        static $instance = null;
        if (null === $instance) {
            $instance = new static;
        }

        return $instance;
    }

    /**
     * Protected constructor to prevent creating
     * a new instance of the *Singleton* via the
     * `new` operator from outside of this class.
     */
    protected function __construct(){}

    /**
     * Private clone method to prevent cloning 
     * of the instance of the *Singleton* instance.
     */
    private function __clone(){}

    /**
     * Private unserialize method to prevent 
     * unserializing of the *Singleton* instance.
     */
    private function __wakeup(){}
}

$obj = Singleton::getInstance();
\var_dump($obj === Singleton::getInstance()); // bool(true)

Example : Config, Logger,

Database Connection

Pros :

  • Memory-leak free
  • Single access to the shared resource

Cons :

  • Used as a GLOBAL instance
  • Hard to TEST, Not able to extend
  • Problem in multithreded language

Factory Pattern

Bridge between Multiple classes.

Return Instance of Several possible classes based on provided data, which have same parents or implementation.

Example : Database Server

Pros :

  • Hide concreate class from client
  • Easy to Plug in new type (of Shape)

Cons :

  • Hard to extend factory interface
  • Increased runtime overhead
  • Infrastructure complexity

Strategy Pattern

Encapsulate specific families of algorithms, allowing the client class responsible for instantiating a particular algorithm to have no knowledge of the actual implementation.

Example :

Output Interface [Array, JSON]

Pros :

  • Runtime algorithm swap
  • Very easy extendable

Cons :

  • Client must aware of difference between strategies
  • Infrastructure complexity

Facade Pattern

Example :

TravelBookingService

[Flights, Hotels, Ship Bookings]

Pros :

  • Isolate client from subsystem component
  • Minimizes coupling between client and subsystem

Cons :

  • Risk becoming to Facade object coupling to all other objects

Wrapper for many sub-system

SOLID Principle

By Robert C. Martin,

Known as Uncle Bob

Object-oriented design(OOD) principles

Single Responsibility Principle

A Class should have only one single responsibility.

One reason to change.

Pros :

  • Smaller class that are easier to read, maintain and test
  • Easy to naming

Cons :

  • Sometime it's overkill the application
  • Hard to refactor the messy class.

Open-Close Principle

Pros :

  • Cascading change through modules or classes
  • Each change require testing

A Class should be OPEN for Extension, and CLOSED for modification

Liskove Substitution Principle

Pros :

  • Child class don't get burden for parents methods if not necessary

Every subclass is substitutable by its parent class.

 

Object of a derived class should be able to replace an object of the base class without bringing any errors in the system or modifying the behaviour of the base class

 

Normal inheritance IS-A relation

LSP IS-SUBSTITUABL-FOR relation

Interface Segregation Principle

Pros :

  • Prefer small and very specific interface
  • Divide FAT interface to slim one
  • No need to implement unused methods

Interface should not force its client to implement anything that client will not use.

Dependecy Inversion Principle

Pros :

  • Loosly coupled
  • Increased testability and Maintainability
  • Flexibility of runtime configuration

Entities must depend on abstractions not on concretions.

High level module must not depend on the low level module, but they should depend on abstractions.

  • Abstractions = Interface
  • Concretion    = Classes

Cons :

  • Can complicate debugging during the learning curve

Other Design Principles

KISS - Keep It Simple, Stupid

DRY - Don't Repeat Yourself

WET - Write Everything Twice

YAGNI - You Ain't Gonna Need It

References

All Images are taken from online

About ME {

name     : Emran Ul Hadi,

      know-me : emran.github.io ,

                 photo    :  





       }

Made with Slides.com