SOLID principy – 5. díl: Princip obrácení zavislostí

POZOR! Článek jsem napsal před více jak rokem, a tudíž už nemusí reflektovat můj nynější názor nebo může být zastaralý.

Video (1:29)

Definice říká, že:

A. Moduly vyšší úrovně by neměly záviset na modulech nižší úrovně. 
Oboje by mělo být  závislé na abstrakci.

B. Abstrakce by neměla záviset na detailech. 
Detaily by měly záviset na abstrakci.

De facto můžeme říct, že byste téměř vždy měli záviset na abstrakci a nikoli na konkrétní implementaci.

Na ukázku máme třídu CarModel, která v konstruktoru vyžaduje připojení k databázi.

<?php

class MySQLConnection
{
    public function connect()
    {
        // Připojení k databázi
    }
}

class CarModel
{
    public function __construct(MySQLConnection $connection)
    {

    }
}

Tahle architektura se někdy označuje jako „naivní“, protože si myslíte, že přece vždy budete používat MySQL. Navíc je třída CarModel hůře testovatelná a přenositelná, protože závisí na konkrétní implementaci a ne na abstrakci.

Abychom se takovéto závislosti zbavili, je potřeba například rozhraní ConnectionInterface, které bude třída MySQLConnection implementovat. Nyní se jen změní závislost v konstruktoru a je hotovo. Pokud budete v budoucnu potřebovat přejít na Oracle, nebude potřeba třídu CarModel měnit.

<?php

interface ConnectionInterface
{
    public function connect();
}

class MySQLConnection implements ConnectionInterface
{
    public function connect()
    {
        // Připojení k databázi
    }
}

class OracleConnection implements ConnectionInterface
{
    public function connect()
    {
        // Připojení k databázi
    }
}

class CarModel
{
    public function __construct(ConnectionInterface $connection)
    {

    }
}

Znáte někoho, komu by článek mohl pomoct? Zasdílejte mu ho :)

Komentáře