Strategy (Strategia)

strategy uml

Opis

Wzorzec projektowy Strategy (Strategia) należy do grupy wzorców behawioralnych. Pozwala odseparować do konkretnych klas właściwe algorytmy z pewnej grupy i dynamicznie korzystać z tego, który akurat jest potrzebny. Świetnie enkapsuluje to zachowanie gwarantując, że klasa kliencka nie wie, który algorytm jest wykonywany. Wystarczy, że spełnia właściwy interfejs. Chyba, że decyzja o strategii nie jest automatyczna i to klient w klasie kontekstowej decyduje z której skorzystać – taka implementacja też jest możliwa.

W nowszej literaturze często nazywany też Policy (Polityka). W tym wpisie używam nazw zamiennie, ale w praktyce częściej sięgam po oryginalną nazwę szczególnie w kodzie.

Problem i rozwiązanie

Skąd wzięła się taka nagonka na ifologię? Przecież to jedna z podstawowych konstrukcji w programowaniu. Okazało się, że kod pisany w ten sposób jest trudny w zarządzaniu, już nie mówiąc o rozszerzeniach. I nie mam na myśli omijania na siłę konstrukcji warunkowych. Zresztą ciężko by się bez nich żyło, ale w niektórych miejscach lepiej skorzystać z dobrodziejstw mechanizmów obiektowych – chociażby polimorfizmu.

Problem wystąpi wszędzie, gdzie pewne zachowanie może być realizowane na różne sposoby. Jak to może wyglądać w praktyce? Do zaimplementowania był prosty mechanizm powiadomień użytkownika o występujących zdarzeniach. Pierwsza iteracja zakładała tylko powiadomienia emailowe – standard w aplikacjach webowych. No to jazda – jedna klasa z obsługą danych zdarzeń, które generują powiadomienie. Jak dobrze poszło to chociaż usługa do wysyłki emaili jako osobna klasa – fajnie, bo przyda się pewnie w innych miejscach.

Przychodzi kolejna iteracja i nagle biznes twierdzi, że przydałoby się żeby również bezpośrednio w aplikacji zalogowany użytkownik był informowany o danych zdarzeniach. Wydaje się, że ma to sens. No więc następuje implementacja samego mechanizmu powiadomień oraz klasa odpowiadająca za informowanie użytkownika zostaje rozszerzona. Wszystko fajnie działa, ale niektórzy użytkownicy są sfrustrowani tym, że dostają podwójne powiadomienia. Najpierw odczytują w systemie, a później to samo mają w skrzynce pocztowej.

W grę wchodzą preferencję użytkownika. Niech sam zadecyduje, czy chce być informowany i w jaki sposób. No więc modyfikowana zostaje klasa do notyfikacji o jakiegoś ifa. Pierwszy problem – czy tę klasę interesuje w jaki sposób ma informować użytkownika? Może wystarczy jej informacja, że zdarzenie wystąpiło i trzeba powiadomić użytkownika w preferowany przez niego sposób.

Inne założenie przy okazji – trzeba dorzucić SMS jako nowy typ powiadomień. Nie wszyscy przeglądają skrzynkę pocztową regularnie, a też rzadko logują się do systemu. Natomiast o niektórych faktach muszą zostać powiadomieni jak najszybciej. SMS wydaje się najskuteczniejszą opcją dla tego rodzaju problemu. Dodanie trzeciego rodzaju algorytmu już okaże się problematyczne. Jakiś elseif albo przerobienie na switcha. Klasa spuchnie dwukrotnie, a przy okazji dodawania nowego typu powiadomień można zepsuć coś w starych, bo klasa wymaga modyfikacji.

Oczywiście do zrobienia i może dramatyzuję, ale jest to na pewno trudniejsze i zajmie dłużej niż gdyby skorzystać z wzorca projektowego Strategy. Nie wspominając o tym, że rezultat będzie mniej czytelny. No nic, zostaje żyć w wierze, że już nie dojdzie kolejny typ informowania użytkownika, a w obecnie zaimplementowanych nic się nie zmieni. Co ciekawe nawet rezygnacja z jakiegoś algorytmu np. SMS też nie będzie aż tak trywialna jak mogłoby się wydawać. A znając życie w kolejnej iteracji czekają powiadomienia Slack i Push Notification.

W dalszej części tego wpisu prezentuję ten sam przykład jako implementację w PHP z wykorzystaniem wzorca Strategii. Dodanie nowego rodzaju notyfikacji w tym przypadku nie będzie stanowiło żadnego problemu. Po prostu nowa strategia, bez ingerencji w klasę, która jest odpowiedzialna za wysyłkę powiadomień. Coś pięknego! Tego typu problemy występują w każdej aplikacji i to bardzo często. Może nie wszystkie rozwiązuje się tym wzorcem projektowym, ale znaczną część z nich można i to ze sporą korzyścią.

Plusy i minusy

Jak to zwykle we wzorcach projektowych minusy są szukane trochę na siłę. Strategia często tworzona jest przez new zamiast użyć DI. Z prostego powodu, jeżeli strategii jest dużo to należałoby przekazać do klasy kontekstowej je wszystkie jako argumenty co mija się z celem. Przecież to też jedna z zalet, że tylko potrzebny obiekt jest tworzony.

Wzorzec projektowy Policy pasuje w wielu miejscach, co może okazać się wadą i zaletą. Uznałem to za minus, jako że nie wszędzie okaże się zgodny z KISS i może niepotrzebnie komplikować, chociaż akurat ten pattern jest dość prosty w rozumieniu.

Plusów można doszukać się więcej. Przestrzegane są dwie pierwsze zasady SOLID – SRP i OCP. Eliminacja dziedziczenia, a zamiast tego wykorzystywana kompozycja. Ograniczenie, bądź pozbycie się zbędnych instrukcji warunkowych, co wpływa na czytelność i łatwiejszą zarządzalność. Mechanizm gwarantuje również enkapsulację konkretnych algorytmów izolując szczegóły implementacyjne od klasy Context oraz zapewniając elastyczność.

Przykładowa implementacja w PHP

Struktura klas we wzorcu projektowym Strategia zawsze będzie taka sama. W implementacji może różnić się natomiast konkretna klasa korzystająca z dobrodziejstw tego mechanizmu. Gdzieś musi dojść do decyzji, która Polityka akurat w tym miejscu ma być wykorzystana. Widziałem sporo implementacji, ale jeszcze nigdy nie znalazłem w pełni odpowiadającej na wszystkie problemy. Warto znać możliwe opcje i dopasować tę najlepszą.

Istnieją dwa popularne rozwiązania. Jedno pozwala klientowi wybrać właściwą dla operacji Strategię przyjmując ją jako parametr, a drugie umożliwia dynamiczne jej określenie na podstawie innego argumentu. Za to momenty do ustalenia Polityki są co najmniej trzy:

  • Konstruktor – przy tworzeniu obiektu dla wszystkich metod klasy;
  • Dedykowana metoda – wywoływana w innej metodzie przed akcją;
  • Parametr metody – interfejs jako typ.

Ja wziąłem na warsztat nieco trudniejszą opcję, bo pozwalającą na wiele strategii dla jednego zachowania. Metoda determineStrategies() jest więc fajną opcją do określenia potrzebnych klas tyle że ma jedną ogromną wadę – tworzenie Strategii przez new. W moim uproszczonym przykładzie – nie ma z tym problemu. W rzeczywistości często klasa może potrzebować zależności. Żeby to rozwiązać można użyć któregoś wzorca kreacyjnego, albo przekazać do konstruktora klasy Notifier jako zależności gotowe już obiekty strategii. Zadziała, ale obiekt mocno puchnie przy kolejnych politykach, a klasa ma sporo zależności, a być może potrzebuje tylko jednej z nich.

Dodatkowa uwaga: uprościłem i notify() zwraca stringa, a normalnie pewnie byłaby to metoda void i wykonywała faktycznie swoje zadanie, czyli wysyłka email lub powiadomienie systemowe. To samo metoda onPasswordExpired() pewnie nie zbierałaby rezultatów, a test wyglądałby zupełnie inaczej. Tak jak zawsze wspominam ma to być konceptualne – myślę, że jak ktoś kojarzy temat to bez problemu dostosuje sobie do własnych potrzeb.

<?php

declare(strict_types=1);

namespace DesignPatterns\Behavioral\Strategy;

interface NotifyInterface
{
    public function notify(string $message): string;
}
<?php

declare(strict_types=1);

namespace DesignPatterns\Behavioral\Strategy;

class EmailNotifier implements NotifyInterface
{
    public function notify(string $message): string
    {
        return sprintf('Email: %s', $message);
    }
}

<?php

declare(strict_types=1);

namespace DesignPatterns\Behavioral\Strategy;

class SystemNotifier implements NotifyInterface
{
    public function notify(string $message): string
    {
        return sprintf('System: %s', $message);
    }
}

<?php

declare(strict_types=1);

namespace DesignPatterns\Behavioral\Strategy;

class NotificationPreference
{
    private bool $email;

    private bool $system;

    public function __construct(bool $email, bool $system)
    {
        $this->email = $email;
        $this->system = $system;
    }

    public function shouldNotifyByEmail(): bool
    {
        return $this->email;
    }

    public function shouldNotifyBySystem(): bool
    {
        return $this->system;
    }
}

<?php

declare(strict_types=1);

namespace DesignPatterns\Behavioral\Strategy;

class UserNotification
{
    public const PASSWORD_EXPIRE_MESSAGE = 'Your password will expire in 3 days. Please change it as soon as possible.';

    public function onPasswordExpired(NotificationPreference $notificationPreference): array
    {
        $messages = [];
        $notifyStrategies = $this->determineStrategies($notificationPreference);
        /** @var NotifyInterface $notifyStrategy */
        foreach ($notifyStrategies as $notifyStrategy) {
            $messages[] = $notifyStrategy->notify(self::PASSWORD_EXPIRE_MESSAGE);
        }

        return $messages;
    }

    private function determineStrategies(NotificationPreference $notificationPreference): array
    {
        $notifyStrategies = [];

        if ($notificationPreference->shouldNotifyByEmail()) {
            $notifyStrategies[] = new EmailNotifier();
        }

        if ($notificationPreference->shouldNotifyBySystem()) {
            $notifyStrategies[] = new SystemNotifier();
        }

        return $notifyStrategies;
    }
}

<?php

declare(strict_types=1);

namespace DesignPatterns\Behavioral\Strategy\Test;

use DesignPatterns\Behavioral\Strategy\NotificationPreference;
use DesignPatterns\Behavioral\Strategy\UserNotification;
use PHPUnit\Framework\TestCase;

final class UserNotificationTest extends TestCase
{
    public function testCanNotifyUserByEmailAboutPasswordExpire(): void
    {
        $userNotificationPreference = new NotificationPreference(true, false);
        $userNotification = new UserNotification();

        $messages = $userNotification->onPasswordExpired($userNotificationPreference);

        $this->assertCount(1, $messages);
        $this->assertContains(sprintf('Email: %s', UserNotification::PASSWORD_EXPIRE_MESSAGE), $messages);
    }

    public function testCanNotifyUserBySystemAboutPasswordExpire(): void
    {
        $userNotificationPreference = new NotificationPreference(false, true);
        $userNotification = new UserNotification();

        $messages = $userNotification->onPasswordExpired($userNotificationPreference);

        $this->assertCount(1, $messages);
        $this->assertContains(sprintf('System: %s', UserNotification::PASSWORD_EXPIRE_MESSAGE), $messages);
    }

    public function testCanNotifyUserByEmailAndSystemAboutPasswordExpire(): void
    {
        $userNotificationPreference = new NotificationPreference(true, true);
        $userNotification = new UserNotification();

        $messages = $userNotification->onPasswordExpired($userNotificationPreference);

        $this->assertCount(2, $messages);
        $this->assertContains(sprintf('Email: %s', UserNotification::PASSWORD_EXPIRE_MESSAGE), $messages);
        $this->assertContains(sprintf('System: %s', UserNotification::PASSWORD_EXPIRE_MESSAGE), $messages);
    }

    public function testCannotNotifyUserWithoutPreferenceAboutPasswordExpire(): void
    {
        $userNotificationPreference = new NotificationPreference(false, false);
        $userNotification = new UserNotification();

        $messages = $userNotification->onPasswordExpired($userNotificationPreference);

        $this->assertCount(0, $messages);
    }
}

Strategy – podsumowanie

Ten wzorzec projektowy jest łatwy w implementacji, a daje wymierne korzyści. Tak jak wspominałem jest on prosty w swoich założeniach. Jeśli programujecie obiektowo już od dłuższego czasu i nie mieliście okazji go zaimplementować to chyba coś jest nie tak. Praktycznie w każdej aplikacji są miejsca, gdzie sprawdzi się idealnie. Polecam zastosować odpowiednią strategię nauki wzorców projektowych i okiełznać go jako pierwszego, zamiast mniej sławnego Singletona.

Krystian Żądło
Programista PHP i właściciel marki Koddlo. Pasjonat czystego kodu i dobrych praktyk programowania obiektowego. Prywatnie fan angielskiej piłki nożnej, dobrego humoru oraz podcastów.