Wzorce projektowe w PHP: Visitor (Wizytator)

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

Pierwszy z serii artykuł traktujący o wzorcach projektowych w PHP. Omówię w nim zasadę działania wzorca projektowego Visitor (Wizytator) i analizując przykłady postaram się zachęcić czytelników do używania go.

Spis treści

Teoria

Wizytator to wzorzec projektowy, który zapewnia nam prosty sposób na wykonanie jednej lub większej ilości operacji na określonej grupie obiektów. Do zaprojektowania wymaganej zależności będziemy potrzebować dwóch interfejsów określających funkcjonalności, które będzie wymagać implementacja. Te dwa interfejsy oddzielą od siebie dwa najbardziej elementarne grupy obiektów zależności - obiekt "odwiedzający" (Visitor) i obiekt "odwiedzany" (Visitable). Zanim przejdziemy dalej proponuję wyobrazić sobie taki obrazek: Jest dom w którym mieszka rodzina składająca się z dwojga dorosłych (matka i ojciec) oraz dziecka. Mamy też człowieka spoza domu, powiedzmy listonosza, który codziennie rano odwiedza dom i mieszkańców. Rolę "magazynu" odgrywa tu dom, mieszkańcy będą osobami odwiedzanymi, a listonosz wizytatorem, który odwiedzając dom i jego mieszkańców ma spełnić swoje określone zadanie. Znamy już podział ról i zależności pomiędzy osobami - obiektami.

Do góry

Abstrakcyjny przykład

Za pomocą kolejnego przykładu przejdźmy do programowania. Wyobraźmy sobie teraz nieco inną sytuację w której mamy rower posiadający dwa koła i pompkę, za pomocą której chcemy je napompować. Potrzebujemy stworzyć 3 obiekty - "Bicycle", "Wheel" oraz "Pump". Rower (Bicycle) będzie "magazynem" kół (Wheel) - obiektów, które mogą zostać odwiedzone przez pompkę (Pump) - wizytatora. Potrzebujemy również wspomnianych wcześniej interfejsów - Visitor i Visitable. Zabawę zacznijmy od interfejsów:

interface Visitor
{
    public function visit(Visitable $visitable);
}
 
interface  Visitable
{
    public function accept(Visitor $visitor);
}

Schemat jest dość prosty - Visitor za pomocą metody "visit" będzie odwiedzać obiekt typu Visitable, a on z kolei będzie mógł zgodzić się na jego wizytę za pomocą metody "accept". Jako, że znamy już zależności pomiędzy naszymi trzema obiektami, jesteśmy w stanie określić, że obiekty "Bicycle" i "Wheel" będą implementować interfejs Visitable - będą odwiedzanymi, a "Pump" - Visitor - będzie odwiedzać.

Zaprogramujmy więc nasze obiekty. Zacznijmy od najbardziej elementarnych, czyli roweru i koła:

class Bicycle implements Visitable
{
    private $wheels = array();
 
    public function addWheel(Wheel $wheel)
    {
        array_push($this->wheels, $wheel);
    }
 
    public function accept(Visitor $visitor)
    {
        foreach($this->wheels as $wheel)
        {
            $wheel->accept($visitor);
        }
    }
}

class Wheel implements Visitable
{
    private $name = null;
 
    public function __construct($name)
    {
        $this->name = $name;
    }
 
    public function getName()
    {
        return $this->name;
    }
 
    public function accept(Visitor $visitor)
    {
        $visitor->visit($this);
    }
}

Funkcjonalność tej klasy także nie powinna być trudna do odgadnięcia. Jest metoda "addWheel", która dodaje na stos obiekt koła. Poznana wcześniej metoda 'accept' zmieniła nieco zachowanie - za zadanie ma wykonanie metody 'accept' na wszystkich kołach ze stosu. Dzięki temu wystarczy, że odwiedzimy obiekt Bicycle. To on zadba o to, aby pompka wszystkie koła.

Na koniec najważniejsza klasa, a mianowicie nasz wizytator w którym zawarta będzie cała funkcjonalność.

class Pump implements Visitor
{
    public function visit(Visitable $visitable)
    {
        echo 'Pompuję koło ' . $visitable->getName() . "..\n";
        // inne operacje na obiekcie $visitable
    }
}

W klasie tej definiujemy metodę 'visit', w której zamieszczamy całą logikę którą ma wykonać obiekt odwiedzający na obiekcie odwiedzanym. Nie musimy się przejmować ile kół tak naprawdę mamy do napompowania - tym zajmuje się inna klasa - Bicycle, skupiamy się tylko i wyłącznie na tym, co mamy zrobić. Dzięki temu zyskujemy wyraźne odseparowanie logiki wykonawczej od struktury i zależności pomiędzy obiektami.

Na koniec stwórzmy obiekty naszych klas i wykonajmy "odwiedzenie". Kod każdej z klas celowo umieściłem w osobnych plikach, aby podkreślić separację i przejrzystość.

<?php
 
// Dołączamy potrzebne pliki
require_once 'Visitor.php';
require_once 'Visitable.php';
require_once 'Pump.php';
require_once 'Bicycle.php';
require_once 'Wheel.php';
 
// Tworzymy obiekt roweru
$bicycle = new Bicycle;
 
// "rejestrujemy" koła
$bicycle->addWheel(new Wheel('przednie'));
$bicycle->addWheel(new Wheel('tylne'));
 
// Pompujemy wszystkie koła odwiedzając obiekt klasy Bicycle obiektem klasy Pump
$bicycle->accept(new Pump);
 
?>

Wynikiem działania tego kodu będzie:

Pompuję koło przednie..
Pompuję koło tylne..

Do góry

Co dalej?

Nic nie stoi na przeszkodzie abo stworzyć kolejnych "wizytatorów", którzy będą wykonywać określone działania. Wykonanie kolejnej serii działań sprowadzać się będzie do dodania jednej linii kodu:

$bicycle->accept(new KolejnaKlasaImplementujacaInterfejsVisitor);

Nie musimy się również ograniczać do odwiedzania obiektów jednego typu. Do naszego roweru możemy dołożyć kierownicę, dynamo i siodełko, a wizytatorem może zostać mechanik, który będzie umiał naprawić dowolną część roweru. Najlepsze jest to, że nie będziemy musieli modyfikować kodu obiektów odwiedzanych, ograniczymy się tylko do stworzenia bardziej elastycznego kody wizytatora, przyjrzyjmy się takiemu przykładowi:

<?php
 
$bicycle = new Bicycle;
 
$bicycle->addElement(new Wheel('przednie'));
$bicycle->addElement(new Wheel('tylne'));
$bicycle->addElement(new SteeringWheel);
$bicycle->addElement(new Saddle);
$bicycle->addElement(new Dynamo);
 
$bicycle->accept(new Mechanic);
 
?>

Metoda 'addElement' w klasie Bicycle może być stworzona na bazie metody 'addWheel' z tą różnicą, że jako argument przyjmować będzie mogła obiekt dowolnej klasy implementującej interfejs Visitable, np.:

    public function addElement(Visitable $element)
    {
        array_push($this->elements, $element);
    }

Klasa wizytatora "Mechanic" będzie musiała być nieco inna, jako że ma posiadać więcej umiejętności:

- pompować koło,
- przykręcać siodełko
- wyprostować kierownicę
- naprawić dynamo

Nie mniej jednak interfejs jej nie zmieni się - od "zewnątrz" będzie to najzwyklejszy Visitor:

class Mechanic implements Visitor
{
    public function visit(Visitable $visitable)
    {
        $methodName = 'visit' . get_class($visitable);
        $this->$methodName($visitable);
    }

    private function visitWheel(Visitable $visitable)
    {
        echo 'pompuję koło ' . $visitable->getName() . '!';
    }
 
    private function visitSaddle(Visitable $visitable)
    {
        echo 'przykręcam siodełko!';
    }
 
    private function visitSteeringWheel(Visitable $visitable)
    {
        echo 'prostuję kierownicę!';
    }
 
    private function visitDynamo(Visitable $visitable)
    {
        echo 'naprawiam dynamo!';
    }
}

Koncepcja jest podobna, lecz metoda 'visit' w tym przypadku wybiera jedynie inną, prywatną metodę o nazwie składającej się z nazwy klasy odwiedzanej, np. 'visitNazwaKlasyElementu'. Do tej metody została przeniesiona cała logika wykonawcza. Dzięki temu osobne metody zajmują się osobnymi częściami roweru.

Do góry

Zastosowanie przy tworzeniu aplikacji WWW

Ten dość ciekawy wzorzec projektowy łatwo znajdzie także zastosowania przy tworzeniu aplikacji WWW. Wszędzie tam, gdzie musimy wykonać serię operacji na danej strukturze danych możemy śmiało go implementować. Przykładem mógłby być koszyk z zakupami w sklepie on-line. Obiekt koszyka (np. iterator) zawiera w sobie obiekty różnego typu, ale posiadające wspólny interfejs. Klasa koszyka pełniłaby funkcję "magazynu" (roweru, czy domu z poprzednich przykładów) implementując interfejs Visitable. Wizytatorem mógłby być obiekt podsumowujący zamówienie w sklepie. Odwiedzałby każdy element w koszyku i pobierając cenę każdego z nich wyliczał kwotę zapłaty. Kolejnym mógłby być mechanizm sprawdzania dostępności produktów w koszyku w magazynie. Możliwości jest wiele.

Do góry