Design patterns 101

Table of Content

• Who is this blog for
• Before you start
• Quick Review
  1. S.O.L.I.D
  2. Dependency injection
  3. Composition and Aggregation
• Design Patterns
• Patterns in the real world

Who is this blog for

• if you want to be a better programmer (reading others code - enhancing your skills).
• if you are repeating yourself when you write code (unintentionally).
• those who think design pattern is a black box and can’t really know what is a design pattern.
• sometimes you see snippet of code that you don’t understand in programming language that you have experience with and you wonder why is this code designed this way.

Before you start

This blog is a brief of 14 design pattern in Head first design pattern, so to get the biggest benefit of this blog, i recommend you follow these steps :-

1. Read the pattern definition.
2. Understand the problem introduced and try to imagine it in bigger scale.
3. Read the UML.
4. Trace the code example.

Two important things you need to know before we go further :-

First

Design pattern is just a clean way to solve a problem also provides flexibility to your code,so do not enhance any pattern until you make sure that this enhancement is successful applied by the SOLID (we will come to this later), so you can consider solid as your brakes that will stops your fantasy from pattern violation.

Second

Patterns are not used separately from each others at the end of this blog you can use many patterns together like you will see in MVC.

This blog is based on this repo so go ahead and star it first then keep going.

Quick Review

S.O.L.I.D

every letter stands for a specific word with a specific concepts so let’s get started right away.

S - Single-responsiblity principle

A class should have one and only one reason to change, meaning that a class should have only one job.

O - Open-closed principle

Objects or entities should be open for extension, but closed for modification.

L - Liskov substitution principle

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

I - Interface segregation principle

A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.

D - Dependency Inversion Principle

Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

• Note : you can find more information about solid and code examples Here.

Dependency injection

we use this technique to provide more functionality to an object from another dependent objects.

Example

here we injected class A to class B.

class A{
	public function show()
	{
		print "Hello from A Class";
	}
}

class B{
	public $A;
	
	public function __construct()
	{
		$this->A = new A();
	}
	
	public function showFromA()
	{
		print $this->A->show();
	}
	
}

$b = new B();
$b->showFromA();

Composition and Aggregation

Composition is effectively an ownership relationship, while aggregation is a “contains” relationship. In composition, the parts can not exist outside the thing that contains them, but individual things can exist on their own as unique entities in aggregation.

in order to keep this blog short and sticky to the point i recommend you read this short blog Composition and aggregation

Design Patterns

follow the link of every pattern to see pattern definition, UML, and code examples

Do not forget to trace the code this is the most important step to get familiar with the pattern

Strategy pattern

Defines a family of algorithms ,encapsulates each one and makes them interchangable. strategy lets the algorithm vary independently

Observer Pattern (Keeping your objects in the know)

Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

you may see this pattern used alot in the front-end framework because it needs to eep track of data synced to the UI.

Decorator Pattern (Decorating Objects)

Decorators provide a flexibile alternative to subclassing extending functionality.

Factory Pattern (Backing with oo Goodness)

Factory pattern divided into two main types (Factory method and Abstract factory), In this pattern i will focus on the difference between the two subset patterns and will code only the factory method.

Check the difference between Abstract Factory and Factory Method

Singleton Pattern (One of a kind object)

Ensure that a class has one instance and provide a global point of access to it ,we can say that this pattern is our ticket to creating one-of-a-kind objects for which there is only one instance.

Command Pattern (Encapsulating Invocation)

Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Adapter Pattern

Convert the interface of a class into another interface clients expect.let’s classes work together that couldn’t otherwise because of incompatible interfaces.

Check the two adapter types

Facade Pattern

Provides a unified interface to a set of interfaces in a subsystem facade defines a higher-level interface that makes the subsystem easier to use.

Template Method Pattern (Encapsulating Algorithms)

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

Iterator Pattern

Provide a way to access of an aggregation object sequentially without exposing it’s underlying representation.

Composite Pattern

Compose objects into tree structured to request part whole hierarchies, Composite let’s clients treat individual objects and compositions of objects uniformly.

Proxy Pattern

Provide a surrogate or placeholder for another object to control access to it

State Pattern

Allow an object to alter its behavior when its internal state changes the object will appear to change its class.

Patterns in the real world

Categorizing patterns will help us understand the difference between patterns and also will help us memorizing them.

Categorize patterns as (Structural - Behavioural - Creational)

Structural

Decorator - Composite - Proxy - Facade - Adapter

Behavioural

Template Method - Iterator - Command - Observer - State - Strategy

Creational

Singleton - Abstract Factory - Factory Method

Categorize patterns that deals with (Class - Object)

Class

Template Method - Adapter - Factory Method

Object

Command - Decorator - Proxy - Composite - Facade - Iterator - Observer - Strategy - Singleton - State - Abstract Method

Thinking in pattern

Keep it simple (KISS)

solve things in the simplest way possible, your goal should be simplicity, not “how should i apply a pattern”.

Design patterns aren’t a magic bullet; in fact, they’re not even a bullet!

patterns aren’t a magic bullet you can’t plug one in, compile and then take an early lunch, to use patterns , you also need to think of the consequences for the rest of your design.

You know you need a pattern when…

once you’re sure a simple solution will not meet your needs, you should consider the problem along with the set of constraints under which the solution will need to operate- these will help you match your problem to a pattern.

if you have any question please open an issue with your question on the github repo Here.

Tweet Share