Design Patterns

Krzysztof Stręk

Backend developer

5 min read
When our project code grows, the code seems to be ok, we successfully wrote on our own problems solutions. They are working, we finished the job. But it is important to look backwards, and ask ourselves what are the conclusions of our work. Maybe someone wrote it better, faster, or what is most important found some universal solution for specific problem, that repeats somewhere in our code or even in most of project. When we think about those, we got that it’s an important thing, that can simplify our work and made code more readable for others. There are many definitions, but most common is that design pattern is a problem solution in certain context. If You are not familiar with design patterns, and don’t now what are the for, I’ll try to explain it on some major popular ones, but first lets get to know what are the consists of.


Design patterns, most of them were analyzed by many smart brains yet. There are plenty of them, but they all have similar structure and became described. Every pattern can be defined fully as it follows:


The main cause of use.

Problem description

What problems does it solves.

Range of application

It's an analysis of where it can be used, implemented - where it's useful.


Visual schema of how it works with other components of project. These are UML diagrams for instance.


More technical info on how to organize code.

Code samples

This is important for coders mainly.

Known implementations

Sometimes problem repeats and have already an implementation or more.

Similar versions

When design pattern is done, it may implicate others. One on another pattern, cause possibility to describe problem by exact patterns, not by code. More of those helps to understand the code structures for programmers.

Decorator Pattern

When we want to extend class it’s simple, we just use extend keyword in our class definition to do that. But what if we don’t want to change class definition? Is there solution for that ? Yes, there is - decorator pattern. It helps to keep original object class with no change inside of it. It’s very useful if for some reason we don’t want to touch original class definition. Let’s take a look at code below, to understand it more.

    interface GreetInterface {
        public function greetMessage();

    class BaseObject implements GreetInterface {
        public function greetMessage() {
            return "Hello there";

    class Decorator implements GreetInterface {
        private $base;
        public function __construct(BaseObject $base) {
            $this->base = $base;
        public function greetMessage() {
            return $this->base->greetMessage()." from decorator";

    $baseObject = new BaseObject();
    $decoretedObject = new Decorator($baseObject);

    echo $decoretedObject->greetMessage() // outputs: "Hello there from decorator"

The Guru Pattern

Universal pattern for every solution - does it exist ? There is one interesting thing, that may be at some part. It is called “Picture that explains almost everything” and the concept is made by Mariusz Gil, specialist in design patterns and code brainstorming. He claims that it can solve almost every problem that is given. Here is the link to the picture on Mariusz Gil’s Twitter:

Picture that explains (almost) everything

Factory pattern

Another useful pattern is mentioned factory pattern. This one stands for creating objects of a different type but associated somehow. We could say that a request is done to the factory, and then it responds with the correct object or default object when the factory doesn’t know what to create. For example, the factory produces pizzas. It’s hard to create pizza with common object creation “new Margherita()” every time. Instead, we just use a static function with the desired pizza type. The code that handles this is much more editable and extendable.

    abstract class Pizza {
        abstract public function get_price();

    class MargeritaPizza extends Pizza {
        public function get_price() {
            return 9;

    class FunghiPizza extends Pizza {
        public function get_price() {
            return 11;

    class ComposePizza extends Pizza {
        public function get_price() {
            return 14;

    class PizzaFactory {
        public static function create_pizza( $type ) {
            switch( $type ) {
                case 'Margerita':
                    return new MargeritaPizza();
                case 'Funghi':
                    return new FunghiPizza();
                    return new ComposePizza();

    $pizza = PizzaFactory::create_pizza( 'Funghi' );
    echo $pizza->get_price();

Our approach

We take care of creating a good code with design patterns usage, so as a beneficent you gain valuable solutions. Thanks for your attention.

Also check