post_ico4

Wzorce projektowe podsumowanie

Na temat wzorców projektowych byłoby póki co tyle ;) Na zakończenie dołączam jeszcze kilka praktycznych przykładów wykorzystania ich w budowie sklepu internetowego.


Przykład 1

Tworzymy sklep internetowy i w specyfikacji mamy określane, że wyświetlana cena ma zależeć od typu klienta (nowy klient, stały klient, hurtownik itp.). Ponadto nie mamy gwarancji, że sposób wyliczania ceny nie zmieni się w przyszłości. Jak odpowiednio zaprogramować ten mechanizm? Najlepiej użyć wzorca strategii. Spójrzmy na przykład:

<?php

interface Price {

    public function count($value);
}

class PriceForNewClient implements Price {

    public function count($value) {
        return 1.20 * $value;
    }

}

class PriceForRegularClient implements Price {

    public function count($value) {
        return 1.15 * $value;
    }

}

class PriceForWholesaler implements Price {

    public function count($value) {
        return 1.10 * $value;
    }

}

class Product {

    private $name;
    private $basicPrice;
    private $strategyPrice;

    public function __construct($name, $basicPrice, $strategy) {
        $this->name=$name;
        $this->basicPrice=$basicPrice;
        $this->strategyPrice = new $strategy();
    }
    public function getPrice() {
        return $this->strategyPrice->count($this->basicPrice);
    }
    public function getName() {
        return $this->name;
    }
    public function setStrategy($strategy) {
        $this->strategyPrice = new $strategy();
    }

}

// testy
$product = new Product("produkt 1", 100, "PriceForNewClient");
echo "Nazwa produktu: ".$product->getName().", cena produktu: ".$product->getPrice()."<br />";
$product->setStrategy("PriceForRegularClient");
echo "Nazwa produktu: ".$product->getName().", cena produktu: ".$product->getPrice()."<br />";
$product->setStrategy("PriceForWholesaler");
echo "Nazwa produktu: ".$product->getName().", cena produktu: ".$product->getPrice()."<br />";

?>

W powyższym przykładzie mamy trzy strategie naliczania ceny zależne od typu klienta. Żeby zmienić sposób wyliczania ceny wystarczy tylko utworzyć nowy obiekt strategii za pomocą setStrategy(). Dzięki zastosowaniu wzorca późniejsze modyfikacje będą znacznie prostsze.

Przykład 2

Kolejnym problemem w naszym sklepie jest sposób generowania różnych widoków. Dla różnego rodzaju porównywarek cenowych listę produktów musimy wygenerować zwykle jako dokument XML, natomiast dla użytkownika potrzebujemy zwykłą stronę HTML. Problem możemy rozwiązać za pomocą fabryki abstrakcyjnej lub metody wytwórczej. Wybierzemy metodę wytwórczą, ponieważ nie potrzebujemy dwóch różnych fabryk. Naszym wymogiem są tylko dwa różne produkty (XML i HTML). Przykład:

<?php

interface IView {

    function render();
}

class HtmlView implements IView {

    function render() {
        // generowanie widoku html
    }

}

class XmlView implements IView {

    function render() {
        // generowanie widoku xml
    }

}

class PdfView implements IView {

    function render() {
        // generowanie widoku pdf
    }

}

class View {

    static function factory($fileName) {
        switch (end(explode('.', $fileName))) {
            case 'html' :
                return new HtmlView();
            case 'xml' :
                return new XmlView();
            case 'pdf' :
                return new PdfView();
            default :
                throw new Exception('nieznany typ pliku');
        }
    }

}

$html = View::factory("strona.html");
var_dump($html);
$xml = View::factory("strona.xml");
var_dump($xml);
$pdf = View::factory("strona.pdf");
var_dump($pdf);

?>

Na podstawie rozszerzenia pliku metoda factory() stworzy obiekt odpowiedniego typu. Tworząc interfejs zapewniamy sobie jednakowe API dla różnych typów dokumentów. Rozwiązanie takie znacznie ułatwia dalszą pracę programisty – nie musi wdawać się w szczegóły techniki generowania danego typu dokumentu, ma do tego zapewnione abstrakcyjne API.

Przykład 3

Nasz sklep internetowy ma być naprawdę rozbudowany ;). Kolejnym problemem jaki możemy napotkać jest stworzenie API, które ułatwi integrację innym serwisom z naszym sklepem. Takie API na pewno musi zawierać metody do logowania, pobierania produktów i kupowania. Dobrze napisana aplikacja funkcje te ma zawarte w różnych klasach (modelach). A więc powstaje pytanie: jak je scalić? Z pomocą przybywa wzorzec fasady

<?php 
 
class User{
    public function login() {
        echo "Logowanie do systemu\n";
    }
    public function register() {
        echo "Rejestracja\n";
    }
}
 
class Cart{
    public function getItems() {
        echo "Zawartość koszyka\n";
    }
}
 
class Product{
    public function getAll() {
        echo "Lista produktów\n";
    }
     
    public function get($id) {
        echo "Produkt o ID ".$id."\n";
    }
}
 
class API{
    private $user;
    private $cart;
    private $product;
     
    public function __construct() {
        $this->user = new User();
        $this->cart = new Cart();
        $this->product = new Product();
    }
     
    public function login() {
        $this->user->login();
    }
     
    public function register() {
        $this->user->register();
    }
     
    public function getBuyProducts() {
        $this->cart->getItems();
    }
     
    public function getProducts() {
        $this->product->getAll();
    }
     
    public function getProduct($id) {
        $this->product->get($id);
    }
}
 
// testy
$client = new API();
$client->register();
$client->login();
$client->getProducts();
$client->getProduct(5);
$client->getBuyProducts();
 
?>

Chyba nie muszę tego fragmentu tłumaczyć :)

Przykład 4

W projektowanym przez nas sklepie mamy zaimplementowany mechanizm cache’owania. Dodatkowo chcemy informować klientów o dodaniu nowego produktu (np. z wybranej przez nich kategorii). Oczywiście wszystko ma się dziać automatycznie. Jak sobie można z tym poradzić? Używając wzorca obserwatora

<?php

class CacheObserver implements SplObserver {

    public function update(SplSubject $subject) {
        echo "Odswieza cache\n";
    }

}

class RSSObserver implements SplObserver {

    public function update(SplSubject $subject) {

        echo "Odswieza RSS\n";
    }

}

class NewsletterObserver implements SplObserver {

    public function update(SplSubject $subject) {

        echo "Wysylam maile z nowym produktem\n";
    }

}

class Product implements SplSubject {

    private $observers = array();

    public function attach(SplObserver $observer) {
        $this->observers[spl_object_hash($observer)] = $observer;
    }

    public function detach(SplObserver $observer) {
        unset($this->observers[spl_object_hash($observer)]);
    }

    public function notify() {
        foreach ($this->observers as $observer) {
            $observer->update($this);
        }
    }

    public function add($data) {
        echo 'Dodaje prodykt do bazy';
        $this->notify();
    }

}

$product = new Product();

$product->attach(new RSSObserver());
$product->attach(new CacheObserver());
$product->attach(new NewsletterObserver());

$product->add(array(
    'name' => 'Nazwa',
    'description' => 'blablabla'
));

?>

W powyższym przykładzie obiekt modelu produktu obserwowany jest przez trzech obserwatorów. W przypadku wywołania metody add(), która zapisuje dane do bazy, zostaną o tym zdarzeniu poinformowani wszyscy obserwatorzy – z kolei oni wykonają odpowiednie czynności takie jak aktualizacja cache, wysłanie maili itp.

PS: Nie wykluczam opisywania kolejnych wzorców w przyszłości :)

PS 2: Cały cykl możecie pobrać stąd.

Powiązane tematy

Co sądzisz o wpisie?
BeżnadziejnySłabyŚredniDobryBardzo dobry (Brak ocen, bądź pierwszy!)
Loading...
  • Janek Kowalski

    Hej,
    Przykład 3:
    public function __construct() {
    $this->user = new User();
    $this->cart = new Cart();
    $this->product = new Product();
    }

    Nie powinno być:
    public function __construct(User $user, etc..) {
    $this->user = $user;etc.
    }$user = new User();

    $client = new API($user, etc..);
    ?
    Type hinting and dependecy inc.