Zasady | Policies
To kolejna świetna technika, która może nam pomóc z zasadami, regułami, warunkami w naszych klasach, a szczególnie w kontrolerach 
.
Po co?
Metoda ta pozwoli nam odpowiednio wyodrębnić wszystkie weryfikacje, które zazwyczaj muszą zajść przed wykonaniem danej akcji (np. jeśli nie jesteś zalogowany - nie możesz przejść dalej).
A niestety zazwyczaj jest ich bardzo wiele. I niestety, ale zazwyczaj lądują w nieodpowiednim miejscu i tam zostają...
I często nawet jest ich o wiele więcej, niż konkretnej i znacznącej logiki aplikacji.
A co najgorsze, jest spora szansa, że sprawdzeń/zasad tych będziesz dokonywał/używał w wielu miejscach. Więc kłania się tutaj również problem redundancji. Okropieństwo.
Właśnie w tym pomogą nam dedykowane klasy Policies .
Jak się za to zabrać?
Zrób nową klasę np. DeleteThreadPolicy (najlepiej utwórz w tym celu dedykowany folder o przykładowej nazwie Policies).
Możemy ustalić, że typowym interfejsem wszystkich klas typu Policy będzie metoda allows().
I do tej klasy należy przenieść wszystkie warunki .
A wszystkie potrzebne dane możemy przekazać poprzez konstruktor (w nowo utworzonej klasie).
Klasę tę będziesz pytał, czy zezwala na jakąś konkretną akcję (do której klasa ta posiada zasady). W tym przypadku akcją tą będzie usuwanie tematu (deleteThread).
Wówczas wystarczy stworzyć nową instancję tej klasy Policy, przekazać dane (jeśli trzeba) i zapytać ją, czy możemy wykonać tę akcję .
Prosta sprawa
Nie jest to trudne prawda? Tak naprawdę po prostu stworzyliśmy prostą klasę... I to ma sens.
I wbrew powszechnej opinii nie ma sensu doszukiwać się tutaj kryjącego za tym wzorca. Bo co by to nie było, to zawsze i tak tylko klasa, która ma jakieś swoje zadanie . Jesteś wolny, pamiętaj. Ty kreujesz klasy i ty nadajesz im sens. Możesz wszystko.
Możesz to rozbudować dużo bardziej... proszę, czemu nie. Wszystko w twoich rękach .
Zalety
Wyabstrahowanie całej logiki związanej z zasadami do eleganckiej klasy, z czytelną nazwą. Klasa Policy która enkapsuluje całą logikę i jest w pełni reużywalna . Świetna sprawa.
Mamy teraz nową możliwość tworzenia dowolnych klas Policies, które mają jasno określone jedno przeznaczenie. I możemy je wspólnie przechowywać w jednym katalogu. Nasz katalog z zasadami.
A cały "śmieciowy" kod z przykładowego kontrolera (który jeszcze pewnie uległby duplikacji w innych miejscach) został usunięty!
Świetna refaktoryzacja. Dokonaliśmy eleganckiego sprzątania i poprawiliśmy architekturę naszej aplikacji. Oraz dodany został kolejny reużywalny element.
Klasa Policy z powyższego przykładu
<?php
namespace App\Policies;
class DeleteThreadPolicy
{
public function allows()
{
// Cała logika autoryzacyjna
}
}
Policies w Laravelu
Warto również wspomnieć, że Laravel posiada swój własny i bardzo rozbudowany koncept Policies. W Laravelu klasy Policy bardziej odnoszą się do wszystkich zasad związanych z danym modelem. Są powiązane z modelami. Do konkretnych akcji natomiast wykorzystuje się zasad Gate .
A sprawdzenie czy jesteśmy zalogowani mamy na starcie za darmo, bez pisania pojedynczej linii kodu. Ponieważ jest to już etap autoryzacyjny. Więc autentykację musimy mieć za sobą.
To wszystko i wiele innych rzeczy ... Ale to temat na osobny artykuł.
Podsumowanie
Nie trzymaj zasad/reguł w nieodpowiednich miejscach. Stosuj Policies zapobiegając tym samym redundancji . Świetna technika, która ma mnóstwo zalet. Lecz jak wszystko, stosuj z rozwagą !
Kończąc
Dziękuję ci za lekturę. Zostaw proszę komentarz i udostępnij ten artykuł jeśli możesz . Zapraszam cię również do lektury innych moich artykułów, szczególnie tych o tematyce refaktoryzacji.
A tymczasem życzę ci dobrego dnia, bywaj !