Wzorce projektowe w PHP: Decorator (Dekorator)

Autor: Bartosz Maciaszek
Data publikacji: 02.11.2007, 11:57 | Ostatnia modyfikacja: 02.11.2007, 11:57

Drugi z serii artykuł omawiający implementację bardzo ciekawego wzorca projektowego w PHP - Dekoratora (ang. Decorator)

Spis treści

Teoria

Nazwy wzorców projektowych nie biorą się z nieba. Teorię tę potwierdza wzorzec dekorator - jak sama nazwa wskazuje służy do dekorowania obiektów, a także innych, nawet elementarnych typów danych. Dekorator w konstruktorze otrzymuje obiekt, który ma udekorować i, co najważniejsze, ze wspólnym interfejsem. Dzięki temu obiekt może być dekorowany kilkukrotnie bez zmiany typu bazowego. Przyjrzymy się kodowi, aby łatwiej było zrozumieć to, co chciałbym zaprezentować.

Do góry

Abstrakcyjny przykład

Wczujmy się w nastrój i omówmy najprostrzy przykład. Załóżmy, że mamy do dyspozycji trzy dekoratory, które w specyficzny sposób zmieniają obiekt wejściowy, który jest najprostrzym stringiem, a raczej obiektem klasy UndecoratedString która posiada jedna składową typu string i implementuje taki oto interfejs:

interface String
{
    public function getString();
}
 
class UndecoratedString implements String
{
    public function __construct($string)
    {
        $this->string = $string;
    }
 
    public function getString()
    {
        return $this->string;
    }
}

Klasą bazową naszych dekoratorów będzie taka oto klasa:

abstract class StringDecorator implements String
{
    protected $decorate = null;
 
    public function __construct(String $string)
    {
        $this->decorate = $string;
    }
 
    public function getString()
    {
        return $this->decorate->getString();
    }
}

Jako argument konstruktora przyjmuje ona obiekt klasy implementującej interfejs String, czyli na przykład naszej UndecoratedString.

Oto nasze trzy dekoratory, wszystkie dziedziczą ze StringDecorator i przysłaniają metodę 'getString' zmieniając jej zachowanie. Przeanalizuj ich kod. Zauważ, że przysłaniając wywołują metodę getString() z klasy przekazanej w konstruktorze. Oczywiście zamiast $this->decorate->getString() moglibyśmy użyć konstrukcji parent::getString(). Efekt byłby identyczny.

class BoldDecorator extends StringDecorator
{
    public function getString()
    {
        return '<b>' . $this->decorate->getString() . '</b>';
    }
}
 
class ItalicDecorator extends StringDecorator
{
    public function getString()
    {
        return '<i>' . $this->decorate->getString() . '</i>';
    }
}
 
class UnderlineDecorator extends StringDecorator
{
    public function getString()
    {
        return '<u>' . $this->decorate->getString() . '</u>';
    }
}

Przejdźmy do sedna, czyli do końcowego kodu wywołującego wszystkie dekoratory.

Stwórzmy obiekt klasy UndecoratedString:

$string = new UndecoratedString('ala ma kota');

Następnie dekorujemy go w taki sposób:

$string = new BoldDecorator($string);
$string = new ItalicDecorator($string);
$string = new UnderlineDecorator($string);
 
echo $string->getString();

Wynikiem działania tego kodu będzie:

<u><i><b>ala ma kota</b></i></u>

Co zyskaliśmy? Uniwersalny i bardzo przeźroczysty mechanizm do zmieniania zachowania lub wyglądu obiektów, który jest zupełnie odseparowany od modelu biznesowego. Każdy dekorator ma określony zakres zmian, które wykonuje i może być z powodzeniem wywoływany bez interferencji z innymi dekoratorami. Dużą zaletą jest to, że w każdym przypadku możemy skorzystać z dowolnej ilości dekoratorów, a dzięki temu, że abstrakcyjny dekorator implementuje ten sam interfejs, co obiekt bazowy (UndecoratedString) nie obserwujemy zmian klas - w każdym miejscu '$string instanceof String' zwróci true.

Do góry

Zastosowanie przy tworzeniu aplikacji WWW

W jaki sposób ten wzorzec projektowy możemy wykorzystać w praktyce? Dobrym przykładem będą wszelkiego rodzaju listingi. Załóżmy, że wykonaliśmy zapytanie do bazy danych, które zwróciło nam taką oto strukturę:

$rows = array
(
    array
    (
        'userId'=> 1,
        'login' => 'mike',
        'email' => 'mike@foobar.com',
        'deletable' => false
    ),
 
    array
    (
        'userId' => 2,
        'login' => 'frank',
        'email' => 'frank@foo.com',
        'deletable' => true
    ),
 
    array
    (
        'userId' => 5,
        'login' => 'lucas',
        'email' => 'lucas@bar.com',
        'deletable' => true
    )
);

Na podstawie tych danych mamy wyświetlić tabelę użytkowników składającą się z trzech kolumn. W pierwszej pojawić się ma login użytkownika podlinkowany do jego szczegółów, w drugiej jego email w postaci linka 'mailto:', a w trzeciej link 'usuń', o ile flaga 'deletable' jest równa true. Na początek musimy określić wspólny interfejs dla niesformatowanego obiektu i dekoratorów:

interface Listing
{
    public function getRow($pos);
    public function getRows();
}

Zaprojektujmy teraz klasę, która "przekonwertuje" naszą strukturę na coś zrozumiałego dla dekoratorów. Na poczet tego tworzymy klasę implementującą powyższy interfejs:

class UnformattedListing implements Listing
{
    private $rows = array();
 
    public function __construct(array $rows)
    {
        foreach($rows as $row)
        {
            // tworzymy obiekt klasy stdClass z tablicy
            $this->rows[] = (object) $row;
        }
    }
 
    public function getRow($pos)
    {
        return $this->rows[$pos];
    }
 
    public function getRows()
    {
        return $this->rows;
    }
}

Jako argument konstruktora dostaje ona dane z bazy, po czym tworzy z kolejnych iteracji obiekty klasy stdClass i umieszcza na stosie. Implementuje oczywiście dwie metody z interfejsu: getRows i getRow, za pomocą których zwraca stworzoną w konstruktorze tablicę lub jej określony element.

Mając dane opakowane w pożądany przez nas interfejs możemy zaplanować abstrakcyjny dekorator, który będzie klasą bazową do wszystkich dekoratorów:

abstract class ListingDecorator implements Listing
{
    protected $decorate = null;
 
    public function __construct(Listing $listing)
    {
        $this->decorate = $listing;
    }
 
    public function getRow($pos)
    {
        return $this->decorate->getRow($pos);
    }
 
    public function getRows()
    {
        $rows = array();
 
        foreach($this->decorate->getRows() as $pos => $row)
        {
            $rows[] = $this->getRow($pos);
        }
 
        return $rows;
    }
}

W klasie tej znajdziemy podstawowe wywołania metod 'getRows' i 'getRow'. Będziemy je przysłaniać w razie potrzeby w końcowych dekoratorach.

Zdefiniujmy teraz nasze dekoratory: AddDeleteLinkDecorator, który w nowym polu o nazwie 'deteleLink' umieści link do usunięcia użytkownika jeżeli pole 'deletable' będzie true, AddEmailLinkDecorator podlinkowujący adres email i AddUserDetailsLinkDecorator dodający link do szczegółów. Przeanalizuj ich kod.

class AddDeleteLinkDecorator extends ListingDecorator
{
    public function getRow($pos)
    {
        $row = $this->decorate->getRow($pos);
 
        $row->deleteLink = $row->deletable ? '<a href="delete.php?userId=' . $row->userId . '">Usuń</a>' : '';
 
        return $row;
    }
}

class AddEmailLinkDecorator extends ListingDecorator
{
    public function getRow($pos)
    {
        $row = $this->decorate->getRow($pos);
 
        $row->email = '<a href="mailto:' . $row->email . '">' . $row->email . '</a>';
 
        return $row;
    }
}

class AddUserDetailsLinkDecorator extends ListingDecorator
{
    public function getRow($pos)
    {
        $row = $this->decorate->getRow($pos);
 
        $row->login = '<a href="details.php?id=' . $row->userId . '">' . $row->login . '</a>';
 
        return $row;
    }
}

Jeżeli wszystko jest jasne przejdźmy do sedna sprawy, czyli do wywołania dekoratorów:

$listing = new UnformattedListing($rows);
$listing = new AddDeleteLinkDecorator($listing);
$listing = new AddUserDetailsLinkDecorator($listing);
$listing = new AddEmailLinkDecorator($listing);
 
print_r($listing->getRows());

W wyniku dostajemy pięknie udekorowane szczegóły, gotowe abyś wsadził je do szablonu HTML. Spróbuj pobawić się usuwając wywołania poszczególnych dekoratorów.

Co zyskujemy implementując wzorzec projektowy Decorator w naszych aplikacjach? Odpowiedź na to pytanie jest prosta: uniwersalność kodu, podział obowiązków pomiędzy odpowiednimi częściami aplikacji, a w końcu możliwość użycia różnych dekoratorów do struktur różnego typu, o ile ich implementacja będzie wystarczająco abstrakcyjna. Kończąc ten artykuł mam nadzieję, że zainspirowałem Cię do korzystania z rozwiązań tego typu.

Do góry