Core Code & Infrastruktura

Najprościej rzecz ujmując - Core Code - jest to kod niezależny od infrastruktury i kontekstu wywołania. Wzorce służące do jego implementacji to: Command, Serwis, Repozytorium, Fabryka, Read Model, Write Model (Encja) czy Value Object. Z drugiej strony mamy tytułową Infrastrukturę do której należą np. implementacje interfejsów repozytoriów czy kontrolery HTTP/CLI. Stosując podział na Core Code i Infrastrukturę realizujemy ważny cel: odseparowanie kodu realizującego funkcjonalność od szczegółów technicznych. Istotnym elementem w poznaniu każdego z tych wzorców jest zrozumienie w jaki sposób działają ze sobą nawzajem, oraz na jakim etapie cyklu życia aplikacji występują. W tym wpisie nie skupie się na wspomnianych wzorcach, ale na istocie tytułowego podziału na Core Code i Infrstrukturę - czyli dlaczego jest on istotny i jakie korzyści przyniesie.  
 

Odseparowanie od Infrastruktury. Why even bother...?

    Odseparowanie od infrastruktury możemy zrealizować poprzez stosowania wyżej wymienionych wzorców. Jakby się na tym zastanowić to pilnując by kod dzielił się na Core Code i Infrastrukturę, realizujemy główne założenia OOP - wprowadzanie warstw abstrakcji. Biorąc za przykłąd Serwis Aplikacyjny - czytając jego kod, nie musimy zaprzątać sobie głowy szczegółami technicznymi zapisu danych do bazu ponieważ Serwis posiada zależność w postaci Interfejs Repozytorium, która skutecznie ukrywa złożoność tego zagadnienia. Jeżeli będziemy potrzebowali tej wiedzy, po prostu wyszukamy Implementacje Repozytorium ukrywającą techniczne aspekty zapisy. Dzięki temu nie jesteśmy zbyt wcześnie obciążeni więdzą, której na danym etapie w ogóle nie potrzebujemy. 

    Często wymienianą zaletą odseparowania Core Code od Infrastruktury jest wymienialność szczegółów implementacyjnych jak np. baza danych. Prawde mówiąc wymiana bazy na inną jest dość rzadko występująca czynność w czasie życia projektu, ale jeżeli bylibyśmy do niej zmuszeni np. z przyczyn wydajnościowych to przy wydzielonej Warstwie Infrastruktury jesteśmy do tego zdolni porównywalnie mniejszym nakładem pracy. Pojęcie szczegółu implementacyjnego nie ogranicza się jedynie do bazy danych, ale jesto to o wiele szersze spektrum, gdzie do Infrastruktury zaliczamy całe frameworki, biblioteki, połączenia z zewnętrznymu systemami. Od wszystkich tych zależności możemy się odgrodzić warstwą abstrakcji co w nieznanej przyszłości może się okazać nieocenioną zaletą. Jak to powiedział Michael Feathers:  

"Avoid littering direct calls to library classes in your code. You might think that you’ll never change them, but that can become a self-fulfilling prophecy"

    Można wywnioskować, że to co robimy to izolowanie się od technologii służącej do realizowania funkcjonalności, która nie definiuje funkcjonalności samej w sobie. Przez to, że mamy fizycznie rozdzielone miejsca obsługi zapisu do bazy danych konkretnej Encji i definicji samej Encji - utrzymanie projektu staje się prostrze. Na przykład chcąc podnieść wersje biblioteki obsługującej połączenie z bazą danych będziemy operowali jedynie na Warstwie Infrastruktury nie ruszając przy tym kwestii biznesowych, w wyniku czego ryzyko nieumyślnego wprowadzenia zmiany funkcjonalności biznesowej znacząco maleje.

Fizyczne rozdzielenie - czyli tworzenie oddzielnych klas domeny problemu oraz infrastrukturowych w osobnych Warstwach. Warstwy według standardowego modelu dzielą się na Aplikację, Domenę oraz Infrastrukturę - realizowane są przez namespace'y. Jest jasno określone, jaką wiedzę mogą posiadać klasy w danej warstwie o bytach (klasy, interfejsy, enum) z innej warstwy. Jako, że PHP natywnie nie ma zaimplementowanego mechanizumu enkapsulacji przestrzeni nazw, nic nie stoi na przeszkodzie by zaimplementować zły kierunek komunikacji np. Wastwa Aplikacji posiada odwołania do klas z Warstwy Infrastruktury. Jedynie dyscyplina developerów w przestrzeganiu zasad może pilnować tej poprawności (być może przy pomocy analizy statycznej).  

    Z wyizolowaną Warstwą Infrastruktury sprawiamy, że możemy stosować TDD bo klasy z Core Code są łatwe w testowaniu jednostkowym. Dodatkowy nakład pracy może prowadzić do powstania modelu domenowego wedle DDD. Stosowanie tych technik niewątpliwie przyczyni się do jakości wytwarzanego oprogramowania. Dodatkowo, tworzenie klas z myślą o odseparowanej infrastrukturze, naturalnie prowadzi do implementacji popularnego wzorca architektonicznego Porty i Adaptery.  

Wewnętrzna jakość oprogramowania

    Przez Jakość Wewnętrzną rozumie się szerokopojętą czytelność kodu, łatwość w utrzymaniu i rozwijaniu aplikacji. Wydaje się, że na jakości kodu zależy głównie programistom, gdyż dla ludzi biznesu jej istotność na pierwszy rzut oka nie jest taka oczywista. Jako że oprogramowanie tworzone jest w sposób iteracyjny, pisane klasy muszą realizować spójne funkcjonalności, tworzyć luźno powiązane większe struktury i być pokryte należytą ilością testów jednostkowych. Nigdy nie wiadomo jakie zmiany najdejdą w kolejnych iteracjach, więc musimy starać się tworzyć solidne elementy budulcowe (klasy/grupy klas/moduły) w całym projekcie. Utrzymując ścisłą dyscypline przy tworzeniu wysokiej jakości oprogramowania sprawiamy, że będziemy mogli modyfikować zachowanie oprogramowania w sposób przewidywalny i bezpieczny, minimalizując ryzyko, że zmiana będzie wymagała dużej przeróbki. 

    Oprogramowanie jest oczywiście tworzone do realizowania celów biznesowych, ale musi ono też służyć developerom. Moglibyśmy napisać kiepski kod spełniający w 100% wymagania klienta (o wysokiej jakości zewnętrznej), ale wprowadzanie zmian w oprogramowaniu niskiej jakości jest skomplikowane, nieprzewidywalne i ryzykowne - z czasem wymagające coraz większej uwagi developera i nakładu czasu. 

Podsumowując: 

1. im łatwiej i pewniej wprowadzać zmiany w oprogramowaniu tym lepiej
   
2. by łatwiej wprowadzać zmiany w oprogramowaniu trzeba pisać kod o wysokiej jakości wewnętrznej
   
3. istnieje szereg technik do osiągnięcia wysokiej jakości kodu   

    Jak widać tematy te są pochodną wydzielania Core Code i wzajemnie się zazębiają. Stosując wzorce Rdzenia Aplikacji będziemy mogli łatwo przetestować jednostkowo tworzone obiekty, co dowodzi że kod jest modułowy oraz niezależny od kontekstu co jest równoznaczne z wysoką jakością.    

Wzorce Projektowe

    Wymienione na samym początku wzorce, pomagają w pisaniu kodu odseparowanego od infrastruktury. Opracowane były na podstawie sumy doświadczeń innych programistów w budowaniu aplikacji webowych. Są one dla programisty zestawem jasno zdefiniowanych i sprawdzonych elementów budulcowych. Stosowanie wzorców sprawia, że kod jest czytelny, modułowy i łatwy w testowaniu. Developer znający całą paletę wzorców może korzystać z niej jak przybornika z narzędziami - dobierając narzędzie najlepiej dopasowane do probelmu. Nie trzeba wtedy wymyślać koła na nowo i zastanawiać się nad tym czy zastosowane rozwiązanie jest dobre. Mając sprawdzony zestaw wzorców oraz posiadając praktyczną wiedzę ich stosowania jesteśmy w stanie modyfikować oprogramowanie szybciej i pewniej. 

    W rękach developera jest to czy poszerza on swoją wiedzę w dziedzinie wytwarzania oprogramowania wysokiej jakości. Zgłębianie informacji na temat wzorców projektowych sprawia że, zaczynamy widzieć więcej. Implementując kod możemy wybiec w przyszość, przewidując jakie będzie niósł ze sobą konsekwencje, przed jakimi potencjalnymi problemami nas chroni, w jaki sposób sprawia że jest wysokiej jakości. Korzystając z danego wzorca dziesiątki bądź setki razy, posługujemy się nim coraz lepiej, widzimy jakie warianty się najlepiej sprawdzają, a w jakich sytuacjach lepiej go nie stosować.

    Można powiedzieć, że przybornik z narzędziami developera uzupełniany jest o nowe elementy gdy poszerza on swoją wiedzę - teoretyczną i praktyczną. Warto szlifować swoje umiejętności posługiwania się tymi narzędziami gdyż bezpośrednio przekładają się na umiejętności tworzenia kodu wysokiej jakości, czyniąc nasza pracę prostszą.

Na sam koniec wrzucam ciekawy cytat Matthias'a Noback'a dający wiele do myślenia:   

 “Software always becomes a mess, even if you follow all the best practices for software design  but I’m convinced that if you follow these practices it will take more time to become a mess  and this is a huge competitive advantage”

Źródła 

Wpis jak i cała koncepcja została zaczerpnięta przede wszystkim z przemyśleń Matthias'a Noback'a (blog) zawartych w jego dwóch książkach:

📕 Advanced Web Application Architecture (2020)
📕 Object Design Style Guide (2019) 

Wzmianka o Wewnętrznej jakości oprogramowania została zaczerpnięta z książki:

📕 Growing Object-Oriented Software, Guided by Tests (2009)

ID w instrukcjach warunkowych

Przykład

    Biznes decyduje się by konkretni użytkownicy mieli naliczani rabat do robionego zamówienia. W tym wpisie nie będę się skupiał na naliczaniu samego rabatu, tylko na to komu ma on zostać przyznany. Poniżej znajduje się najprostsza implementacja tego zadania: 

 

namespace App\Context\Application;

final class OrderService 
{
	// ...
	public function createOrder(
		//...
		User $user	
	): void {
		// ...
		if (in_array($user->id(), [101,102])) {
			// give a discount
		}
		// ...
	}
} 

 

    Jak widać rabat dotyczy tylko użytkowników z ID 101 & 102.❌ Serwis Aplikacyjny ma teraz wiedzę o konkretnych ID z bazy MySQL, które nie powinny wychodzić poza Warstwę Infrastruktury. Można by utworzyć dodatkową klasę, która hermetyzowała by identyfikatory, ale tak czy inaczej musiałaby się znaleźć w Warstwie Aplikacji (lub co gorsza Domeny). Najprostrzym rozwiązaniem będzie wprowadzenie wyspecjalizowanego Repozytorium składającego się na interfejs:

namespace App\Context\Application\Repository;

interface UserDiscountRepository 
{
	public function discountAllowed(int $userId): bool;
}

Oraz jego implementacji InMemory:

namespace App\Context\Infrastructure\Repository;

use App\Context\Application\Repository\UserDiscountRepository;

final class UserDiscountInMemoryRepository implements UserDiscountRepository 
{
	public function discountAllowed(int $userId): bool 
	{
		return in_array($userId, [101,102]);
	}
}

 

    Wystarczy dodać zależność w postaci UserDiscountRepository do Serwisu Aplikacyjnego. W przypadku gdy będziemy rozwijać funkcjonalność, a użytkownicy z naliczanym rabatem będą dodawani do systemu dynamicznie - implementacja OrderService nie powinna ulec zmianie.

 

namespace App\Context\Application;

use App\Context\Application\Repository\UserDiscountRepository;

final class OrderService 
{
	public function __construct(
		private UserDiscountRepository $userDiscountRepository
	) {}
	
	// ...
	public function createOrder(
		//...
		User $user	
	): void {
		// ...
		if ($this->userDiscountRepository->discountAllowed($user->id())) {
			// give a discount
		}
		// ...
	}
}

Źródło danych InMemory

Często dodając nowe funkcjonalności opieramy się na schemacie: 

1. pobieranie danych ze bazy danych...
   
2. ...przeprowadzanie na nich pewnych operacji
   

    Niekiedy dane te nie zmieniają się w czasie, są z góry ustalone i w związku z tym nie muszą być umieszczane w zewnętrznych bazach typu MySQL/Redis. Możemy bardziej skłaniać się ku przechowywaniu ich bezpośrednio w repozytorium kodu PHP. Przykładowymi danymi tego typu może być tablica asocjacyjna reprezentująca flow zmiany statusów jakiejś konkretnej Encji. Tak mogłaby prezentować się jej przykładowa implementacja:

namespace App\Context\Domain;

final class ChangeStatusProvider 
{
	public static function mapping(): array 
	{
		return [
			1 => 4,
			2 => 5,
			3 => 5
		];
	}
}

Albo z wykorzystaniem stałych:

namespace App\Context\Domain;

interface ChangeStatusProvider 
{
	public const MAPPING = [
		1 => 4,
		2 => 5,
		3 => 5
	];
}

    Klasa tego typu sama w sobie nie nastręcza problemów, ale sposób jej wykorzystania przez klienta już może. Jako klienta możemy wyobrazić sobie Value Object, który jest polem Encji, a ta elementem Agregatu. Można założyć, że ta tablica asocjacyjna nie może znajdować się bezpośrednio wewnątrz Value Object'u ponieważ jest wykorzystywana również przez innego klienta w zupełnie innym kontekście.

ValueObject wywołuje wewnętrznie metodę statyczną w celu pobrania danych.

Wspomniany Value Object będzie odpowiadał za zwracanie nowego statusu, pytać o niego będzie Encja, a Encje - Agregat.  

namespace App\Context\Domain\ValueObject;

use App\Context\Domain\ChangeStatusProvider;

final class SomeValueObject 
{
	// ...
	public function nextStatus(): int
	{
		$newStatus = ChangeStatusProvider::MAPPING($this->status);
		//...
		return $newStatus;
	}
	//...
}

    Dla klienta (Encji) nie ma różnicy czy otrzymany nowy status został wstrzyknięty przez konstruktor Value Object'u, czy tak jak teraz - pochodzi z metody statycznej. Nie ma znaczenia bo otrzymuje gotowy Value Object jako parametr konstruktora. Dla niego wygląda po prostu jak integralna część Value Object. Wszystko więc wygląda dobrze do czasu...

Zmiany wymagań biznesowych

    Okazuje się że, z czasem Biznes oczekuje konfigurowalnych zmian stanu. Administratorzy aplikacji mają mieć możliwość modyfikowania flow zmiany stanu według określonych ram. Dla developerów będzie to oznaczało, że mapowania statusów nie będą dłużej realizowane przez klasę/interfejs ChangeStatusProvider. Zostanie utworzona tabela w relacyjnej bazie danych + prosty interfejs do zarządzania jej zawartością. 

    W obszarze aplikacji przedstawionym w przykładzie, musimy dokonać zmian. Value Object musi teraz otrzymywać dane z zewnątrz (poprzez konstruktor). Dane o mapowaniu statusów pochodzić będą z nowo utworzonego Repozytorium. Jeżeli instancje Value Object tworzymy wewnątrz Serwisu Aplikacyjnego/Fabryki to tam będzie musiało być wstrzyknięte wspomniane Repozytorium. Gorzej jeżeli odbywa się to wewnątrz Agregatu lub Encji - wtedy dane z Repozytorium będą musiały być przekazane przez kolejne warstwy co jest utrudnieniem w implementacji zmian (jest to ciekawy temat na inny wpis).     

    W tym przypadku, do tego typu implementacji nigdy by nie doszło gdyby developer nie zdecydował się na przechowywanie danych w metodzie statycznej (lub stałych klasy). Głównym czynnikiem, który za to odpowiada jest nierozważanie danych z metody statycznej jako danych zewnętrznych. Gdyby od razu zostało przyjęte takie założenie, programista pewnie z automatu: 

1. utworzyłby interfejs Repozytorium (Warstwa Aplikacji)

namespace App\Context\Application;

interface StatusRepository 
{
	/** @return array<int, int> */
	public function mapping(): array;
}

2. jego implementacje (Warstwa Infrastruktury)

namespace App\Context\Infrastructure;

use App\Context\Application\StatusRepository; 

final class StatusInMemoryRepository implements StatusRepository 
{
	/** @inheritDoc */
	public function mapping(): array 
	{
		return [
			1 => 4,
			2 => 5,
			3 => 5
		];
	}
}

3. dane do modeli domenowych (Encji/Value Object'ów) wprowadzane by były przez ich konstruktor/metody

namespace App\Context\Application;

final class AggregateFactory 
{
	public function __construct(
		// ...
		private StatusRepository $statusRepository,
		// ...
	) {}

	public function create(/*...*/): Aggregate 
	{
		// ...
		$someValueObject = new SomeValueObject(
			// ...
			$this->statusRepository->mapping()
			// ...
		);
		// ...
	}
}

 

    Dlatego istotne jest by - za każdym razem gdy zamierzamy umieścić dane w kodzie PHP - zastanowić się czy nie będzie prowadziło to do wyżej opisanych problemów w przyszłości. Mając to na uwadze, możemy ułatwić sobie i innym utrzymanie i rozwój projektu. A więc zamiast refaktoryzować metody statyczne w kierunku Wzorca Repozytorium, należy zaimplementować od razu takie rozwiązanie. Dodatkowo należy pilnować by dane do Agregatów, Encji, Value Object'ów przekazywane były przez ich konstruktory.   

Commandy Aplikacyjne niezależne od infrastruktury (cz. 1)

    Załóżmy, że posiadamy obiekt Data Transfer Object np. Command. Obiekt tego typu zajmuje się jedynie przechowywaniem danych i nie oferują żadnych zachowań poza udostępnianiem swojego stanu. Wykorzystujemy go do przekazywania parametrów do konkretnego Serwisu Aplikacyjnego realizującego funkcjonalność biznesową. W uproszczonej formie klasa typu Command przechowująca dane potrzebne do utworzenia użytkownika prezentowałaby się następująco:     

namespace Application;

final class CreateUserCommand 
{
	public function __construct(
		public readonly string $email,
		public readonly int $type,
		public readonly \DateTimeImmutable $birthDate
	) {} 
}

     

    Jako, że obiekty te tworzone są na podstawie danych z poza granic aplikacji, np. z Request'a HTTP, mogą posiadać Fabryczne Metody Pomocnicze które tworzą instancję na podstawie danych z m.in.:

• JSON/XML z ciała Request'a HTTP
• argumentów Command'a CLI
• obiektu Symfony Form
• danych z pliku CSV

 

Budowanie Command na podstawie zewnętrznych danych

    JSON na podstawie którego budujemy obiekty Command pochodzi z poza granic naszej aplikacji tzw. Outside World. Jest on wysłany po HTTP pomiędzy różnymi aplikacjami.

JSON z poza granic aplikacji. Obiekt Command jest budowany na jego podstawie.

 

    Jak wynika z diagramu, Command budowany jest na podstawie danych z obiektu JSON. Pomimo tego, że znajduje się on w Warstwie Aplikacji, jego instancjonowanie ma miejsce w Warstwie Infrastruktury - w tym przypadku Kontrolerze HTTP. 

Przyjrzyjmy się najpierw samemu obiektowy JSON: 

{
	"email": "john.doe@gmail.com",
	"user_type": 2,
	"birth_date": "1992-11-05"
}

Wiedza jaką powinna dysponować klasa która będzie go odczytywać to:

• jakie posiada klucze

• jakiego typu wartości dany klucz może przechowywać
  

Warto zaznaczyć, że te informacje pochodzą z wspomnianego Outside World. Oto przykład klasy odpowiadającej za mapowanie JSON'a do obiektu Command:

 

namespace Infrastructure;

use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Application\CreateUserCommand;

final class UserController 
{
	public function createUserAction(Request $request): Response 
	{
		/** @var array $payload */
		$payload = $request->getParsedBody();
		
		$command = new CreateUserCommand(
			$payload['email'],
			$payload['user_type'],
			new \DateTimeImmutable($payload['birth_date'])
		);
	
		// ...
	}
}

 

    Jak widać Kontroler z Warstwy Infrastruktury posiada wiedzę o strukturze zewnętrznego obiektu, ale jest to nieco naiwna implementacja. Nie możemy ufać klientowi, co do tego czy dostarczył prawidłową strukturę/dane. JSON może 💣 nie zawierać danego klucza bądź 💣 przechowywać nieoczekiwane wartości. Moglibyśmy ograniczyć się do sprawdzenia czy dany klucz istnieje, w przeciwnym wypadku zadając NULL oczekując tym samym wyrzucenia TypeError (przechwycony gdzieś wyżej):

 

try {
	$command = new CreateUserCommand(
		$payload['email'] ?? null,
		$payload['user_type'] ?? null,
		isset($payload['birth_date']) 
        	? new \DateTimeImmutable($payload['birth_date'])
            : null
	);
	// ...
} catch (TypeError $e) {
	// ...
}

 

Bądź użyć asercji (również rzucających wyjątkiem InvalidArgumentException), które bardziej opisowo przedstawiają warunki które ma spełniać poprawny Request Payload:

try {
	Assert::notEmptyString($payload['email'] ?? null);
	Assert::integerish($payload['user_type']  ?? null);
	Assert::stringDateTime($payload['birth_date']  ?? null);

	$command = new CreateUserCommand(
		$payload['email'],
		(int) $payload['user_type'],
		new \DateTimeImmutable($payload['birth_date'])
	);
	// ...
} catch (InvalidArgumentException $e) {
	// ...
}

 

Warto zauważyć, że wiedza na temat struktury JSON'a pozostaje na poziomie Warstwy Infrastruktury i nie przenika do Warstwy Aplikacji. Jak widać Akcja Kontrolera stała się dość obszerna ponieważ w przeważającej części zajmuje się tworzeniem poprawnego obiektu Command. Warto zastanowić się nad czytelniejszym rozwiązaniem.

Command z Metodą Fabryczną

    Można by pokusić się o przeniesienie kodu odpowiadającego za interpretację JSON'a (ze świata zewnętrznego) do samej klasy Command:

final class CreateUserCommand 
{
	public function __construct(
		public readonly string $email,
		public readonly int $type,
		public readonly \DateTimeImmutable $birthDate
	) {} 
	
	/** 
	 * @param array<int|string, mixed> $payload 
	 * @throws InvalidArgumentException on invalid payload
	 */
	public static function createFromRequest(array $payload): self 
	{
		Assert::notEmptyString($payload['email'] ?? null);
		Assert::integerish($payload['user_type']  ?? null);
		Assert::stringDateTime($payload['birth_date']  ?? null);
		
		return new self(
			$payload['first_name'],
			(int) $payload['user_type'],
			new \DateTimeImmutable($payload['birth_date'])
		);
	}
}

 

    Znacznie uprościło by to implementację Kontrolera ponieważ utworznie obiektu Command sprowadzało by się tylko do jednej linii...

$command = CreateUserCommand::createFromRequest($payload);

...Ale

❌ Warstwa Aplikacji byłaby zależna od JSON'a z poza granic aplikacji. Na każdą zmianę struktury JSON'a (Warstwa Infrastruktury) np. zmiany nazwy klucza z snake_case na camelCase, musielibyśmy modyfikować byt z rdzenia aplikacji w postaci Command'a Aplikacyjnego. Pomimo, że nazwa klucza może się wydawać tylko niewinnym string'iem to tak naprawdę jest to zależność, a w tym przypadku - błędnie ukierunkowana zależność.

Command Aplikacyjny jest bezpośrednio zależny od Warstwy Infrastruktury.

❌ Command posiada od teraz dwie odpowiedzialności: przechowywanie danych & mapowanie obiektu JSON na swój stan. Dwie odpowiedzialności === dwa powody do zmian.  

❌ dodanie obsługi kolejnych mediów przekazu (np. CLI Command) sprawia, że klasa staje się coraz większa.

Pragmatyzm

    Jak wynika z analizy powyżej, umieszczanie kodu interpretującego JSON'a w Warstwie Aplikacji to rozwiązanie łamiące zasady czystego kodu. Z drugiej strony pozostawienie go w Kontrolerze HTTP też nie wydaje się słuszne. W nadchodzącym wpisie zostanie opisane jeszcze jedno rozwiązanie: wprowadzenie klasy Fabrycznej odpowiadającej za powiązanie JSON'a z Command'em. Można zastanowić się czy tworzenie nowej klasy dla tego typu zadania nie jest przerostem formy nad treścią. Jeżeli patrzymy tylko pod kątem czytelności, to dodanie Metody Fabrycznej do Command'a wydaje się zadowalające ponieważ w jednym miejscu mamy powiązane ze sobą zagadnienia. Dodatkowo programiści, jeżeli będą chcieli utworzyć nową instancję Command'a nie będą musieli szukać dodatkowych Klas Fabrycznych - wszystko mają pod ręką. 

    Z drugiej strony, gdy zależy nam na utrzymaniu odpowiedniego kierunku zależności - Metoda Fabryczna nie spełnia tego wymagania. Zależności do Warstwy Infrastruktury są niejawne i subtelne ponieważ opierają się jedynie na string'owym kluczu array'a otrzymanego jako parametr. Nie zmienia to jednak faktu, że jakakolwiek zmiana w obiekcie JSON będzie musiała być naniesiona w Warstwie Aplikacji. Wymienione wyże typy array i string sprawiają wrażenie, że nie niosą ze sobą obciążenia zależnościami. Gdyby były reprezentowane przez Value Object'y z Warstwy Infrastruktury, zależności stałby się jawne i od razu widoczne w sekcji use klasy CreateUserCommand.   

SOLID - zasada Open/Closed w praktyce

 

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"

 

    Analiza dotyczyła będzie rozbudowania kodu o nową funkcjonalność bez  modyfikowania istniejących klas. Spotkałem się z sytuacją gdzie klasa budująca model domenowy na podstawie danych wyciągniętych z bazy danych powinna też tworzyć całe kolekcje takich modeli. Można by:

1.  zmodyfikować klasę budowniczego dodając nową metodę buildCollection(int ...$ids): array,
   

2.  istniejącą metodę budowniczego build($id): Model wywołać w pętli w klasie klienta,
   

Wiele zapytań do bazy

    Drugie rozwiązanie z perspektywy zasady Open/Closed wydaje się lepsze bo nie wymaga od nas modyfikacji istniejącego kodu, ale wiąże się z nim pewien problem. W ciele metody Builder::build wykonywane jest zapytanie do bazy danych (RepositoryInterface::featchById) przez co im więcej obiektów do utworzenia tym gorzej dla optymalności rozwiązania. 

Jedno zapytanie do bazy

    Można zaimplementować jednak rozwiązanie nie ingerujące w istniejący kod wykonujące tylko jedno zapytanie do bazy. Dzięki temu, że klasa Builder posiada wiedzę tylko o interfejsie repozytorium możemy utworzyć kolejną implementację RepositoryInterface - InMemoryRepository.

InMemoryRepository posiada naprawdę prosta implementację i to na jej podstawie będzie tworzony obiekt Builder w klasie klienta zwracającego kolekcje modeli.

 

final class InMemoryRepository implements RepositoryInterface 
{
	/**
     * @param Row[] $rows
     */
	public function __construct(private array $rows) {}
	
	public function featchById($id): ?Row 
    {
		return $this->rows[$id] ?? null; 
	}
	
	/** 
     * @return Row[] 
     */
	public function featchByIds(int ...$ids): array 
    {
		return array_filter(
			$this->rows,
			static fn (Row $row): bool => in_array($row->id(), $ids);  
		);
	}
}

Pozostaje tylko napełnić instancję InMemoryRepository danymi z już istniejącego PDORepository. 

 

Query: GetModel (dotychczasowe) 

    Istniejąca funkcjonalność pobierania tylko jednego modelu zamknięta jest w klasie GetModel która realizuje tą funkcjonalność na podstawie obiektu Builder pobranego z kontenera zależności.

Odbywa się tu tylko jedna istotna czynność:

$this->builder->build($id);

 

Query: GetModelCollection (nowe)

W przeciwieństwie do poprzedniej klasy GetModel tutaj będziemy bezpośrednio operować na PDORepository (pod przykrywką RepositoryInterface). Dzieje się tutaj o wiele więcej niż w poprzednim przypadku:

1. pobranie danych z bazy RepositoryInterface::featchByIds,
2. utworzenie na ich podstawie instancji InMemoryRepository,
3. utworzenie instancji Builder na podstawie InMemoryRepository,
4. wywołanie metody Builder::build w pętli.
   

/** 
 * @return Model[]
 */
public function __invoke(int ...$ids): array
{
	$builder = new Builder(
		new InMemoryRepository(
			$this->repository->featchByIds(...$ids)
		)
	);
	
	return array_map([$builder, 'build'], $ids);
} 

Podsumowanie

• ✅ Nie zmodyfikowaliśmy żadnej istniejącej klasy,
  
• ✅ nowa funkcjonalność bazuje na działających już wcześniej klasach,
• ❌ kolejne użycie słowa kluczowego "new" dla klasy Builder,
• ❌ Repository::fetchByIds musi być idealnie zgrane z wywołaniem Builder::build() w pętli. Repository musi dawać gwarancję, że zawsze zwracany jest komplet danych, w przeciwnym razie powinien wyrzucać wyjątek @throws NotFoundAllIds

    Dzięki takiej implementacji nie ingerowaliśmy w działający koda, a do nowej funkcjonalności wykorzystaliśmy sprawdzone/przetestowane klasy. Dodatkowo rozwiązanie jest całkowicie odseparowane (nowa klasa Query) dzięki temu w całości zachowaliśmy funkcjonalność pobierania pojedynczego modelu.

    Takie podejście uwydatnia swoje zalety gdy proces budowania modelu w budowniczym jest skomplikowany a sam Builder posiada wiele zależności.     

 

Przeciążanie w PHP

Przeciążanie pól klasy

__get(string $propertyName): mixed
__set(string $propertyName, mixed $value): void

✅ gdy pole klasy jest z modyfikatorem dostępu protected i private,
✅ pola które nie są jawnie zadeklarowane,
❌ gdy pole jest publiczne,
❌ gdy pole jest publiczne i z wartością NULL,
❌ gdy wcześniej dynamicznie przypisaliśmy do pola jakąś wartość,


__isset(string $propertyName): bool
__unset(string $propertyName): void

__isset() wzbudzane przez: 

• isset(),
• empty(),
• operator ??

__unset() wzbudzane przez:

• unset(),

✅  gdy pole klasy jest z modyfikatorem dostępu protected i private,

✅  gdy pole klasy nie jest jawnie zadeklarowane,
❌ gdy pole jest publiczne,
❌ gdy pole jest publiczne i z wartością NULL,
❌ gdy wcześniej dynamicznie przypisaliśmy do pola jakąś wartość,

Tutaj możemy być zdezorientowani przez to, że pola klasy mogą przyjmować wartości które np. w normalnym użyciu z konstruktem empty() mogą być rozpatrywane pozytywnie (zwracać true) dla wartości: (int) 0, (string) '0', (double) 0.0, (array) [], null. Tak naprawdę __isset() będzie wzbudzane tylko gdy pole jest ukryte przez modyfikator protected/private albo nie jest zadeklarowane - wartość nie ma znaczenia. 

Przeciążanie metod klasy 

     Do przeciążania metod klasy można wykorzystać magiczną metodę __call() wzbudzaną w w przypadku gdy metoda klasy jest prywatna bądź nie jest zadeklarowana.  

class Person {

/**
* @var string
*/
private $email;

public function __construct(string $email) {
    $this->email = $email;
}

public function getEmail(): string {
return $this->email;
}

private function getFirstName(): string {
    return 'nie wywołane';
}

public function __call(string $methodName, array $args) {
return $args[0];
} 
}

$obj = new Person('johny@mail.com');
echo $obj->getEmail();            // johny@mail.com
echo $obj->getFirstName('Jason'); // jason
echo $obj->getLastName('Doe');    // Doe

Przeciążanie konstruktora klasy

    By przeciążyć konstruktor też musimy zastosować obejście ponieważ PHP nie pozwala na deklarowanie kilku konstruktorów naraz. Tak jak w przypadku przeciążania metod klasy, tak i tutaj problemem może być brak wsparcia ze strony IDE (nie będzie podpowiadać oczekiwanych parametrów) jak i ścisła dyscyplina przestrzegana przez developerów podczas projektowania i instancjonowania klas. Do wykonania zadania wykorzystam funkcję: 

• func_num_args(): int 
• Zwraca wartość typu Integer reprezentującej ilość przekazanych do funkcji argumentów,
• func_get_arg(int $argNumber): mixed
• Zwraca przekazany do funkcji argument o zadanym indeksie, zaczynając od zera,   
• func_get_args(): array
• Zwraca argumenty w kolejności w jakiej zostały przekazane w kodzie klienckim w tablicy - opcjonalnie zamiast dwóch poprzednich funkcji,

W normalnym przypadku klasę można zaprojektować w taki sposób:

class Person {

    public function __construct(

        string   $username, 

        DateTime $birthDate) {

        $this->username  = $username;

        $this->birthDate = $birthDate;

    }

}

    Jak widać każde z pól jest TypeHint'owane na konkretny typ co jest dobrą praktyką ;). Jednak nas interesuje bardziej dynamiczne rozwiązanie, które będzie w stanie imitować przeciążanie konstruktora - oczywiście z perspektywy kodu klienckiego. Oto przykład takiej implementacji:

class Person {
    public function __construct() {
        if (func_num_args() === 2) {
            
            if (false === is_string(func_get_arg(0))) {
                throw new TypeError('First param must be string');
            }

            if (false === func_get_arg(1) instanceof DateTime) {
                throw new TypeError('Second param must DateTime instance');
            }

            $this->username  = func_get_arg(0);
            $this->birthDate = func_get_arg(1);
  
        } else if (func_num_args() === 4) {
            if (false === is_string(func_get_arg(0))) {
                throw new TypeError('First param must be string');
            }

            if (false === is_string(func_get_arg(1))) {
                throw new TypeError('First param must be string');
            }

            if (false === is_string(func_get_arg(2))) {
                throw new TypeError('First param must be string');

            }

            if (false === func_get_arg(3) instanceof DateTime) {
                throw new TypeError('Second param must DateTime instance');
            }

            $this->username  = func_get_arg(0);
            $this->firstName = func_get_arg(1);
            $this->lastName  = func_get_arg(2);
            $this->birthDate = func_get_arg(3);
        } else {
            throw new ArgumentCountError('only 2 or 4 arguments'); 
        }     
    }
}

    Efekt końcowy jest taki, że nasz konstruktor jest przygotowany pod dwa zestawy argumentów, ciało funkcji jest dość obszerne, a przez to mało czytelne. W przypadku np. czterech zestawów argumentów, implementacja konstruktora w najlepszym przypadku była by tylko dwa razy większa. Czy jest to dobre podejście do projektowania klas? moim zdaniem nie. Za każdym razem przed tworzeniem obiektu trzeba będzie zaglądać do pliku z klasą bo nasze IDE nie podpowie nam nic o wymaganych argumentach. Jedynym ratunkiem będzie właśnie przeczytanie DocBlocka, analiza kodu bądź zdanie się na własną pamięć. Można było by wykorzystać opcjonalne argumenty w sygnaturze konstruktora - oszczędzała by ilość kodu potrzebną do implementacji, lecz sprawiła by że całość stała by się mniej plastyczna :

class Person {
    public function __construct(
         string   $username, 
         DateTime $birthDate,
        ?string   $firstName = null,
        ?string   $lastName  = null 
    ) {
        $this->username  = $username;
        $this->birthDate = $birthDate;
        $this->firstName = $firstName;
        $this->lastName  = $lastName;
    }
}

Teraz musimy pilnować by dodatkowe argumenty zawsze były na końcu no i nie wszystkie przypadki dynamicznych zestawów możemy 'obsłużyć'.

• metody magiczne możemy wywoływać bezpośrednio w kodzie klienckim,
• jak zadeklarujemy metodę __call() tylko z jednym argumentem to dostaniemy nieprzechwytywalny Fatal Error, 
• w przypadku gdy w metodzie __set() zadeklarujemy return, nie zostanie wyrzucony Fatal Error ale słowo kluczowe return zostanie zignorowane,
• Gdy poza funkcją będziemy próbowali użyć funkcji func_get_args(), func_num_args(), func_get_arg(1): otrzymamy Warning'a,

Źródła:

• https://www.php.net/manual/en/language.oop5.overloading.php#object.isset

Standardowe błędy PHP

Dzielą się na FATAL i NON-FATAL:

                                                                                                                               
+---------------------------------------------------------+         
|                          E_ALL                          |
+---------------------------------------------------------+ 
   __            __             __          __          __
  |  |          |  |           |  |        |  |        |  | 
  ERROR   RECOVERABLE_ERROR   WARNING     NOTICE    DEPRECATED
  |  |          |  |           |  |        |  |        |  | 
CORE_ERROR      |  |        CORE_WARNING   |  |        |  |  
  |  |          |  |           |  |        |  |        |  |
COMPILE_ERROR   |  |       COMPILE_WARNING |  |        |  | 
  |  |          |  |           |  |        |  |        |  |
USER_ERROR      |  |       USER_WARNING USER_NOTICE USER_DEPRECATED
  |  |          |  |           |  |        |  |        |  |
  PARSE         |  |           |  |        |  |       STRICT
  |  |          |  |           |  |        |  |        |  | 
__|  |__      __|  |__       __|  |__    __|  |__    __|  |__  
\      /      \      /       \      /    \      /    \      / 
 \    /        \    /         \    /      \    /      \    / 
  \  /          \  /           \  /        \  /        \  /
   \/            \/             \/          \/          \/  

+-----------------------+    +-------------------------------+
|         FATAL         |    |           NON FATAL           |
+-----------------------+    +-------------------------------+ 


Możemy też przyjąć inny podział, ze względu na poziom zagrożenia: 

+-----------------+  +-----------------+  +-----------------+
|      NOTICE     |  |     WARNING     |  |      ERROR      |
|                 |  |                 |  |                 |
| *NOTICE         |  | *WARNING        |  | *ERROR          |
| *USER_NOTICE    |  | *USER_WARNING   |  | *USER_ERROR     |
| *STRICT         |  | *COMPILE_WARNING|  | *COMPILE_ERROR  | 
| *DEPRECATED     |  | *CORE_WARNING   |  | *CORE_ERROR     |
| *USER_DEPRECATED|  |                 |  | *PARSE          |
|                 |  |                 |  | *RECOVERABLE    |
+-----------------+  +-----------------+  +-----------------+

ze względu na jego źródło:

+-----------------+  +-----------------+  +-----------------+
|       USER      |  |    COMPILER     |  |     RUNTIME     |
|                 |  |                 |  |                 |
| *USER_ERROR     |  | *PARSE          |  | *ERROR          |
| *USER_WARNING   |  | *CORE_ERROR     |  | *STRICT         |
| *USER_ERROR     |  | *CORE_WARNING   |  | *RECOVERABLE    |
| *USER_DEPRECATED|  | *COMPILE_ERROR  |  | *WARNING        |
|                 |  | *COMPILE_WARNING|  | *NOTICE         |
|                 |  |                 |  | *DEPRECATED     |
+-----------------+  +-----------------+  +-----------------+

czy są możliwe do przechwycenia przez procedurę obsługi zadeklarowaną w funkcji set_error_handler():

⛔ E_ERROR
⛔ E_PARSE
⛔ E_CORE_ERROR, E_CORE_WARNING
⛔ E_COMPILE_ERROR, E_COMPILE_WARNING
⛔ E_STRICT (większość)
✅ E_NOTICE
✅ E_WARNING
✅ E_DEPRECATED
✅ E_RECOVERABLE_ERROR
✅ E_USER_ERROR, E_USER_WARNING, E_USER_DEPRECATED, E_USER_NOTICE

Jest tak ponieważ możliwe do obsługi są jedynie błędy występujące w czasie run-time, wyjątkiem od tej reguły jest E_ERROR i E_STRICT. Warto nadmienić, że konfiguracja zawarta w funkcji error_reporting() nie będzie mieć wpływu na to czy handler przechwyci błąd czy nie.


 E_WARNING  - (2) ostrzeżenie powstałe w czasie wykonywania (run-time) - nie powoduje zatrzymania wykonywania kodu. Wyrzucane gdy:

❌ inkludujemy nieistniejący plik,
❌ użyjemy nieistniejącej stałej,
❌ wywołujemy nie-statyczną metodę klasy w statyczny sposób,
❌ nie zapewnimy wszystkich wymaganych argumentów funkcji/metody klasy, ale tylko do wersji 7.0 włącznie. Od PHP 7.1 wyrzucony będzie Error ArgumentCountError. W przypadku gdy funkcja będzie wymagała dwa argumenty, a wywołując ją nie dodamy żadnego, będziemy mieli dwa wywołane komunikaty ostrzegające.

Różne sposoby by ostrzeżenia NIE pokazywać: 

• error_reporting(E_ALL ^ E_WARNING);
• error_reporting(E_ALL & ~E_WARNING);
• ini_set('error_reporting', E_ALL & ~E_WARNING);
• error_reporting(E_ERROR | E_STRICT);

 E_COMPILE_WARNING  (128) - ostrzeżenia wygenerowane w czasie kompilowania skryptu przez silnik Zend domyślnie logowany do pliku error_log. Tego typu komunikaty otrzymać można wywołując taki kod:

echo "some message";

declare(unexistedDirective='someValue');

Tak jak w przypadku zwykłego ostrzeżenia, wykonywanie programu nie zostanie przerwane lecz z tą różnicą, że komunikat ostrzeżenia wyświetli się na samym początku:

Warning: Unsupported declare 'unexistedDirective'
some message

Jak widać developer nie jest jawnie informowany o ostrzeżeniu w czasie kompilacji, więc można to łatwo pomylić ze zwykłym ostrzeżeniem. Warto mieć to na uwadze podczas implementacji custom'owego handler'a z rozróżnieniem na poszczególne błędy. 

 E_CORE_WARNING  (32)   - generowany przez silnik PHP w czasie jego inicjalizacji.

 E_USER_WARNING  (512) - możliwy do wygenerowania przez developera za pomocą funkcji trigger_error().

 E_NOTICE  - (8) nie do końca jest to błąd ponieważ podczas wykonywania kodu powodującego ten komunikat, proces nie zostaje wstrzymany. Jest to po prostu informacja dla programisty, że coś przebiegło nie tak. Kilka przykładów, które powodują wygenerowanie tego komunikatu:

❌ użycie zmiennej która nie istnieje,
❌ użyjemy pola obiektu które nie istnieje,
❌ odwołanie się do indeksu tablicy, który nie istnieje,


Ukrycie komunikatu: error_reporting(E_ALL ^ E_NOTICE);

bądź w pliku php.ini deklarując wartość dyrektywy na to samo co w nawiasach funkcji error_reporting().

 E_USER_NOTICE  (1024) - możliwy do wygenerowania przez developera za pomocą funkcji trigger_error() przekazując tylko jeden argument typu String będący wiadomością. Drugi argument nie jest konieczny ponieważ jego wartość domyślna to 1024.


 E_STRICT  - (2048) - Jest to podpowiedź od interpretera, że konkretne rozwiązanie nie jest najlepszym standardem/dobrą praktyką lub może zostać wycofane w przyszłych wersjach języka. Wchodzi w skład predefiniowanej stałej E_ALL dopiero od wersji PHP 5.4 choć dostępny jest od 5.0. Od wersji 7.0 już nie zdarzy się nam ujrzeć tego typu błędu ponieważ został zastąpiony komunikatami NOTICE, WARNING czy DEPRECATED. Ze względu na utrzymanie kompatybilności wstecznej stała E_STRICT została jednak zachowana. Powodem tych zmian było zapewnienie prostszego systemu błędów w PHP w którym rola E_STRICT była dość niejasna. Więcej informacji na ten temat znajduje się w linku RFC:reclassify_e_strict. We wcześniejszych wersjach języka błąd E_STRICT otrzymywaliśmy np. gdy:


❌ odwoływaliśmy się do nie-statycznej metody klasy w sposób statyczny,
❌ sygnatura metody w klasie jest inna niż sygnatura tej samej metody w nad klasie,
❌ w klasie zadeklarujesz dwa konstruktory: za pomocą metody magicznej __construct() i starym sposobem gdzie nazwa konstruktora jest taka sama jak nazwa klasy. 

❌ masz metodę która zwraca array'a, wywołujesz ją w funkcji array_pop() - dostajesz komunikat: DEBUG Only variables should be passed by reference.

❌ zadeklarujemy sygnaturę abstrakcyjnej metody statycznej,


 E_DEPRECATED  (8192)  E_USER_DEPRECATED  - (16384) - dostępne od wersji 5.3. Jest to ostrzeżenie wyrzucane w czasie run-time o użytych w kodzie funkcjach\klasach\konstruktach czy rozwiązaniach, które będą wycofane w przyszłych wersjach języka. O tym czy dany wyżej wymienione będą uznawane za przestarzałe decydują ludzie zaangażowani w rozwój języka. Komunikaty te będą się różnić w zależności od wersji języka z której aktualnie korzystasz. W przypadku własnych bibliotek, sam możesz wygenerować błąd E_USER_DEPRECATED za pomocą wbudowanej w język funkcji user_error() będącej aliasem trigger_error() np w taki sposób:

trigger_error('Some message', E_USER_DEPRECATED);

Co powoduje wyrzucenie komunikatu E_DEPRECATED:

7.3

❌ podczas deklarowania stałej case-insensitive za pomocą funkcji define() - czyli przekazując jako trzeci parametr TRUE,

❌ flagi dla funkcji filter_var(): FILTER_FLAG_SCHEME_REQUIRED, FILTER_FLAG_HOST_REQUIRED.

7.2

❌ korzystanie z create_function(), each(),  __autoload(),

❌ rzutowanie wartości na NULL: (unset) $someVariable,

❌ dyrektywa php.ini track_errors,

❌ assert() z parametrem typu String,

❌ zmienna $php_errormsg,

❌ używanie funkcji parse_str() bez podawania drugiego argumentu,

7.1

❌ korzystanie z rozszerzenia mcrypt z racji tego, że nie jest wspierane i trudne w użyciu. Usunięty z PHP w wersji 7.2 i zasobów PECL,

❌ modyfikator e dla funkcji (Multibyte String Function) mb_ereg_replace() i mb_eregi_replace(),

7.0

❌ konstruktory klasy w stylu PHP 4 czyli taki gdzie nazwa funkcji jest taka sama jak nazwa klasy w której się znajduje,

Wymienione wyżej przypadki zostaną usunięte w PHP 8.0.

 E_RECOVERABLE_ERROR  (4096) - dostępny od wersji 5.2. Jest to właściwie Fatal Error możliwy do przechwycenia przez handler zdefiniowany za pomocą funkcji set_error_handler(). Kod który powoduje wyrzucenie tego komunikatu jest poważnym błędem, ale nie pozostawia silnika PHP w niestabilnym stanie, dlatego jeżeli tylko zostanie przechwycony, wykonywanie programu nie zostaje przerwane (w przeciwnym razie program zachowa się jak w przypadku E_ERROR).

Co wyrzuca 'odzyskiwalne błędy' pisałem w tym wpisie. To jedyne przypadki, które udało mi się jak dotąd namierzyć. Ale... instancjonowanie obiektu Closure inaczej można obsłużyć w zależności od wersji:

PHP 5.6 w set_error_handler() ponieważ wyrzucany jest E_RECOVERABLE_ERROR.

PHP 7.0: w bloku try/catch ponieważ wyrzuci to E_ERROR.

Co ciekawe w przypadku błędów związanych z __toString() (ze wspomnianego wpisu) one w dalszym ciągu są obsługiwane przez set_error_handler().




 E_ERROR  (1) - błąd krytyczny wywoływany w czasie wykonywania powodujący wyświetlenie komunikatu typu Fatal Error, a w związku tym natychmiastowe przerwanie skryptu. Przechwycenie tego typu błędu we własnej procedurze obsługi zadeklarowanej za pomocą funkcji set_error_handler() nie jest możliwe. Różnica między PHP 5.6 a 7.0 jest tak, że teraz mamy możliwość godnego obsłużenia niektórych błędów krytycznych:

Błędy które do wersji 5.6  powodowały nieobsługiwane Fatal Error'y, a od 7.0 można je przechwytywać w bloku try/catch, TypeHint'ując na klasę Error:
⚡ wywołanie nieistniejącej funkcji,
⚡ instancjonowanie nieistniejącej klasy,
⚡ instancjonowanie interfejsu,
⚡ odwołanie się do nieistniejącego statycznego pola klasy,
⚡ odwołanie się do nieistniejącej metody statycznej klasy,

Błędy które nawet w wersjach 7.x nie są możliwe do obsługi:
❌ implementowanie interfejsu który nie istnieje,
❌ dziedziczenie po nieistniejącej klasie,
❌ próba przypisania do pola, pola statycznego, stałej klasy innej wartości niż literał np. funkcji anonimowej,
❌ dodanie ciała metody w interfejsie,
❌ próba przypisania wartości do $this,
❌ stosowanie isset() na literałach np. isset(0.0);



 E_CORE_ERROR  (16) - generowany przez silnik PHP. Błąd wystąpi gdy mamy PHP 5.4 (i większe) a w php.ini mamy zadeklarowaną dyrektywę safe_mode=On. Kod developera nie zostaje w ogóle wykonywany.

 E_COMPILE_ERROR  (64) - wyrzucane gdy na zmiennej będziemy próbowali zastosować ::class. Otrzymamy wtedy komunikat: FATAL ERROR Dynamic class names are not allowed in compile-time ::class fetch.

 E_USER_ERROR  (256) - możliwy do wygenerowania przez developera za pomocą funkcji trigger_error()i tym razem - inaczej niż w przypadku E_ERROR - możliwy do obsługi za pomocą set_error_handler().


 E_PARSE  (4) - pojawia się gdy kompilator nie może zinterpretować kodu developera - niemożliwy do obsługi w jakikolwiek sposób. Powoduje wyświetlenie komunikatu typu Parse error: syntax error. Kod developera nie zostaje w ogóle wykonywany. Występuje między innymi w następujących przypadkach zaimplementowanego kodu:

❌ final interface MyInterface {}
❌ abstract interface MyInterface {}
❌ class MyClass() {}
❌ echo 'something'
❌ if (if(true) {} else {}) {}

 FATAL ERROR  - jest to błąd krytyczny i gdy wystąpi następuje przerwanie wykonywania programu. Domyślne zachowanie sprowadza się do wyświetlenia komunikatu błędu.

 FATAL ERROR: UNCAUGHT ERROR  - jest to Fatal Error możliwy do przechwycenia. Dopisek Uncaught error daje informację o tym iż jest to błąd do przechwycenia w klauzuli try/catch, a więc TypeHint'ując w bloku catch na klasę Error albo Throwable mamy możliwość jego obsługi. Procedura obsługi w funkcji set_error_handler() nie jest w stanie obsłużyć tego błędu. Rozszerzony komunikat Fatal Error pojawił się dopiero w PHP 7.0.

 FATAL ERROR: UNCAUGHT EXCEPTION  - tak samo jak powyżej analogicznie do nieprzechwyconych wyjątków (czyli jak ich jawnie nie obsłużymy to zamieniają się w Fatal Error'y).

Standardowe błędy PHP i klasa ErrorException

Dokumentacja zaleca by przechwytywać ostrzeżenia WARNING czy komunikaty NOTICE w procedurze obsługi zdefiniowanej w funkcji set_error_handler() i tam wyrzucać wyjątek ErrorException (PHP 5.1) stworzony z intencją o takim zastosowaniu. Dzięki temu będziemy mogli obsłużyć wyrzucone ostrzeżenie (przykład poniżej) w kontekście jego wywołania:


set_error_handler(function(int $errorCode) {
    if ($errorCode === E_WARNING) {
        throw new ErrorException('Some warning');
    }
});

try {
    echo A;
} catch (ErrorException $e) {
    echo $e->getMessage();
}

Na sam koniec wrzucam fajny kalkulator do wyliczania kodu błędów. 

Źródła:

• https://github.com/php/php-src/pull/3770
• https://www.php.net/manual/en/migration71.deprecated.php
• https://hackernoon.com/deprecations-and-changes-for-php-7-3-avoid-errors-7a5c4dbeaa8b
• https://wiki.php.net/rfc/engine_exceptions_for_php7
• https://wiki.php.net/rfc/reclassify_e_strict
• https://stackoverflow.com/questions/8768149/what-sort-of-issue-would-generate-an-e-compile-warning-in-php
• https://www.php.net/manual/en/features.safe-mode.php
• https://raygun.com/blog/php-error-reporting/
• https://www.php.net/manual/en/function.set-error-handler.php