Klasy PHP - Jak pisać czysty kod? Poradnik krok po kroku

Obiekty i klasy porządkują kod wtedy, gdy zwykłe funkcje przestają wystarczać. W praktyce pozwalają zamknąć dane, metody i reguły działania w jednym miejscu, więc aplikacja staje się łatwiejsza do rozwijania, testowania i poprawiania. Poniżej pokazuję, jak działają w PHP, jak czytać ich składnię oraz kiedy warto po nie sięgać, a kiedy lepiej zostać przy prostszym podejściu.

Czym są klasy i kiedy naprawdę pomagają

Klasa to opis tego, jak ma wyglądać i działać pewien byt, na przykład użytkownik, koszyk, produkt albo zamówienie. Obiekt jest już konkretnym egzemplarzem utworzonym na podstawie tego opisu. Jeśli klasa dobrze pasuje do problemu, kod przestaje być zlepkiem luźnych funkcji i zmiennych, a zaczyna przypominać uporządkowany model domeny.

Ja zwykle sięgam po klasy wtedy, gdy dana rzecz ma nie tylko dane, ale też zachowanie. Użytkownik ma imię, e-mail i status aktywności, ale też może się aktywować, dezaktywować albo zwrócić pełną nazwę. To jest naturalny materiał na klasę. Z kolei jednorazowe przetworzenie tablicy CSV albo prosty skrypt administracyjny często w ogóle nie potrzebuje rozbudowanej struktury obiektowej.

Najprostsza zasada brzmi tak: jeśli element aplikacji ma stan i logikę, klasa zwykle pomaga; jeśli to tylko krótka operacja na danych, klasę można sobie oszczędzić. Dzięki temu nie tworzysz architektury na wyrost. To prowadzi prosto do pytania, z czego dobra klasa powinna się składać.

Z czego składa się dobra klasa w PHP

W praktyce klasa w PHP opiera się na kilku prostych elementach: właściwościach, metodach, konstruktorze i odwołaniu do bieżącego obiektu przez `$this`. To niewiele, ale właśnie z tego powstaje czytelny model. Im szybciej nauczysz się czytać ten układ, tym łatwiej będzie ci analizować gotowy kod i pisać własny.

class User
{
    private string $name;
    private string $email;
    private bool $active;

    public function __construct(string $name, string $email, bool $active = true)
    {
        $this->name = $name;
        $this->email = $email;
        $this->active = $active;
    }

    public function activate(): void
    {
        $this->active = true;
    }

    public function getLabel(): string
    {
        return $this->name . ' <' . $this->email . '>';
    }
}

W tym przykładzie najważniejsze jest to, że dane nie są rozrzucone po całej aplikacji. Konstruktor dba o startowy stan, metoda `activate()` zmienia zachowanie obiektu, a `getLabel()` zwraca gotowy wynik bez wyciągania szczegółów na zewnątrz. To właśnie połączenie danych i logiki daje klasom realną wartość, a nie sam fakt, że kod został opakowany w słowo `class`.

W dalszej części ważna staje się jeszcze jedna rzecz: kto może te dane odczytać lub zmienić. I tu wchodzimy w widoczność, czyli jeden z najważniejszych elementów dobrego projektu obiektowego.

Widoczność pól i metod, czyli kontrola nad danymi

PHP daje trzy poziomy widoczności: `public`, `protected` i `private`. To nie jest detal składniowy, tylko narzędzie do utrzymania porządku. Gdy wszystko jest publiczne, obiekt przestaje kontrolować własny stan. Gdy dane są ukryte, klasa może pilnować zasad, na przykład nie dopuścić do ujemnej liczby sztuk albo pustego adresu e-mail.

W praktyce najczęściej trzymam właściwości jako `private`, a na zewnątrz wystawiam tylko te metody, które są naprawdę potrzebne. Dzięki temu klasa sama pilnuje swoich reguł. Publiczne właściwości mają sens w prostych obiektach transferowych albo w bardzo lekkich modelach danych, ale nie powinny być domyślnym wyborem. Jeśli dane po utworzeniu nie mają się już zmieniać, warto też rozważyć `readonly`, bo to dodatkowo zmniejsza ryzyko przypadkowych błędów.

Gdy model zaczyna rosnąć, pojawia się naturalne pytanie o ponowne użycie kodu. I tutaj wchodzą dziedziczenie, abstrakcja, interfejsy oraz traitsy, czyli mechanizmy, które łatwo pomylić, jeśli patrzy się na nie zbyt powierzchownie.

Dziedziczenie, abstrakcja, interfejsy i traitsy

To cztery różne narzędzia i dobrze jest je rozdzielać już na starcie. Dziedziczenie służy do budowania relacji typu „jest czymś”, interfejs określa „co obiekt potrafi”, abstrakcja daje wspólny szkielet, a trait pozwala współdzielić fragmenty implementacji między klasami, które nie muszą być ze sobą powiązane hierarchicznie.

Najczęstszy błąd, jaki widzę, to sięganie po dziedziczenie tylko dlatego, że „tak się da”. W wielu projektach lepsza okazuje się kompozycja, czyli składanie obiektów z mniejszych części. Jeśli zamówienie ma klienta, adres dostawy i listę pozycji, to nie próbuję robić z tego jednej wielkiej rodziny klas. Lepiej, żeby każda część odpowiadała za własny fragment logiki. Dziedziczenie zostawiam wtedy, gdy zależność jest naprawdę naturalna i stabilna.

Żeby to nie było zbyt teoretyczne, warto zobaczyć klasę, która rozwiązuje konkretny problem. Poniżej przykład prostego elementu koszyka, który pokazuje, jak dane i walidacja mogą pracować razem.

Jak wygląda praktyczna klasa w projekcie sklepowym

Załóżmy, że pracujesz nad koszykiem zakupowym. Każda pozycja ma nazwę, liczbę sztuk i cenę jednostkową, ale nie chcesz dopuszczać wartości absurdalnych, takich jak zero sztuk albo ujemna cena. W takim przypadku klasa przejmuje odpowiedzialność za pilnowanie zasad już na poziomie obiektu.

class CartItem
{
    private string $name;
    private int $quantity;
    private int $unitPriceInGrosze;

    public function __construct(string $name, int $quantity, int $unitPriceInGrosze)
    {
        if ($quantity < 1) {
            throw new InvalidArgumentException('Ilość musi być większa od zera.');
        }

        if ($unitPriceInGrosze < 0) {
            throw new InvalidArgumentException('Cena nie może być ujemna.');
        }

        $this->name = $name;
        $this->quantity = $quantity;
        $this->unitPriceInGrosze = $unitPriceInGrosze;
    }

    public function getTotalInGrosze(): int
    {
        return $this->quantity * $this->unitPriceInGrosze;
    }
}

Ten przykład jest prosty, ale dobrze pokazuje sens klas. Walidacja siedzi obok danych, więc nie musisz sprawdzać wszystkiego w pięciu różnych miejscach aplikacji. Do tego celowo użyłem groszy, a nie liczby zmiennoprzecinkowej. Przy pieniądzach to bezpieczniejszy wybór, bo unikasz błędów związanych z dokładnością obliczeń. Takie szczegóły robią różnicę, zwłaszcza gdy projekt zaczyna się rozrastać.

Oczywiście sam dobry przykład nie wystarczy, jeśli kod potem rozpadnie się przez złe nawyki. Dlatego warto znać najczęstsze pułapki, które regularnie widzę w projektach początkujących i średniozaawansowanych.

Najczęstsze błędy, które psują projekt

Największy problem z klasami nie polega na tym, że są trudne. Problem polega na tym, że łatwo je nadużyć. Kiedy projekt rośnie, kuszą skróty i szybkie obejścia, ale to właśnie one później najdrożej kosztują.

• Zbyt wiele odpowiedzialności w jednej klasie. Jeśli jeden obiekt waliduje dane, zapisuje do bazy, wysyła maila i jeszcze formatuje HTML, to jest już za dużo.
• Wszystko publiczne. Publiczne właściwości są wygodne na start, ale szybko rozwalają kontrolę nad stanem obiektu.
• Dziedziczenie zamiast kompozycji. Nie każde podobieństwo oznacza, że trzeba budować hierarchię klas.
• Brak typów. Typowane parametry i właściwości od razu wyłapują część błędów.
• Zbyt ogólne nazwy typu `Helper`, `Manager` albo `Service` bez konkretnego zakresu odpowiedzialności.

Ja zwykle trzymam się prostej zasady: jeśli klasy nie da się opisać jednym zdaniem, prawdopodobnie robi za dużo. Jeśli z kolei jej jedyną funkcją jest opakowanie jednej linijki kodu bez żadnego sensu organizacyjnego, też nie ma powodu, żeby ją utrzymywać. Dobra klasa porządkuje kod, a nie tylko go powiela.

Ostatni element układanki to funkcje, które nie zawsze są potrzebne na starcie, ale bardzo pomagają w prawdziwych projektach. To one odróżniają znajomość samej składni od pracy w rzeczywistym kodzie aplikacyjnym.

Co warto znać obok samej składni

Jeśli chcesz pisać klasy wygodnie i bez chaosu, nie zatrzymuj się na samym `class` i `public function`. W praktyce bardzo przydają się też nazwy przestrzeni, automatyczne ładowanie klas oraz nowoczesne właściwości języka, które poprawiają czytelność i bezpieczeństwo kodu.

• Namespaces pomagają uniknąć konfliktów nazw, gdy projekt rośnie i pojawia się wiele klas o podobnych nazwach.
• Autoloading pozwala ładować klasy wtedy, gdy są potrzebne, zamiast ręcznie składać pliki `include` i `require`.
• Typed properties sprawiają, że od razu wiadomo, jaki typ danych ma przechowywać właściwość.
• Readonly pasuje do obiektów, które po utworzeniu nie powinny już zmieniać stanu, na przykład prostych DTO.
• Property hooks przydają się wtedy, gdy trzeba przechwycić odczyt lub zapis właściwości, ale nie są pierwszym wyborem dla prostych modeli.

W praktyce nie warto od razu sięgać po każdy nowy mechanizm tylko dlatego, że istnieje. Lepiej najpierw mieć prostą i czystą klasę, a dopiero później dołożyć elementy, które naprawdę rozwiązują problem. To podejście oszczędza czas i zmniejsza liczbę zaskoczeń przy dalszym rozwoju aplikacji.

Co odróżnia dobrą klasę od tylko działającej

Dobra klasa nie musi być rozbudowana. Musi być czytelna, spójna i przewidywalna. Jeśli ktoś otwiera plik za trzy miesiące i od razu rozumie, za co odpowiada obiekt, to znaczy, że projekt idzie w dobrą stronę.

• Ma jedno główne zadanie.
• Ukrywa swój stan, zamiast wystawiać wszystko publicznie.
• Waliduje dane w miejscu, w którym te dane są tworzone lub modyfikowane.
• Nie wymaga zgadywania, co zrobi metoda po wywołaniu.
• Da się ją testować bez uruchamiania połowy systemu.

Jeżeli trzymasz się tych zasad, klasy w PHP przestają być abstrakcyjną teorią, a stają się praktycznym narzędziem do pisania kodu, który da się utrzymać. I właśnie o to chodzi w dobrym programowaniu webowym: nie o efektowną składnię, tylko o kod, który po prostu dobrze pracuje w czasie.