2026.06.10.
Kódolás, keretrendszerek

PHP osztályok titkosításának alapelvei!

Temesvári László

Az OOP Kövei: Private és Public Függvények PHP-ben

Bevezetés: Miért Számít a Láthatóság?

Az objektum-orientált programozás (OOP) nem csupán a kód szervezésének eszköze, hanem egy filozófia, amely a robusztus, biztonságos és karbantartható szoftverek építését segíti. Ennek egyik alapvető pillére a láthatósági módosítók (*visibility modifiers*) használata, amelyek meghatározzák, hogy egy osztály adattagjaihoz és metódusaihoz hogyan lehet hozzáférni. A PHP-ben a public, private és protected módosítók közül a public és a private alkotja a legszembetűnőbb és gyakorlatiasan legfontosabb kettőst. E cikk célja, hogy gyakorlati példákon és konkrét hibákon keresztül megértesse ezek szerepét és használatának fontosságát.

—

Az Alapok: Public vs. Private

Egy public metódus vagy tulajdonság nyilvános interfészt kínál. Bárhonnan, akár az osztályon kívülről is, elérhető és meghívható. Ez a „kapu”, amin keresztül az objektummal kommunikálunk.

Egy private metódus vagy tulajdonság viszont kizárólag az adott osztályon belülről érhető el. Ez a belső működés rejtett mechanikája, amelyet az osztály saját maga használ, de kívülről nem lehet közvetlenül manipulálni vagy meghívni.

A kulcs a kapszulázás (*encapsulation*) elvében rejlik. Nem az a cél, hogy mindent elrejtsünk, hanem hogy védelmet és kontrollt építsünk be az objektum belső állapota köré.

—

Gyakorlati Példa: Egy Egyszerű „BankSzamla” Osztály

Nézzünk egy klasszikus példát, amely szemlélteti a kétféle láthatóság használatát.

<?php

class BankSzamla {
    // PRIVATE tulajdonság: kívülről NEM közvetlenül módosítható
    private float $egyenleg = 0.0;
    private string $tulajdonos;

// PUBLIC konstruktor: az objektum létrehozásának interfésze
    public function __construct(string $tulajdonos) {
        $this->tulajdonos = $tulajdonos;
    }

// PUBLIC metódus: a felhasználó ezen keresztül "további" pénzt
    public function befizet(float $osszeg): void {
        if ($osszeg > 0) {
            $this->egyenleg += $osszeg;
            $this->naploz("Befizetés", $osszeg);
        } else {
            throw new InvalidArgumentException("A befizetés összegének pozitívnak kell lennie!");
        }
    }

// PUBLIC metódus: kontrollált pénzkivétel interfésze
    public function kivesz(float $osszeg): float {
        if ($osszeg > 0 && $this->egyenleg >= $osszeg) {
            $this->egyenleg -= $osszeg;
            $this->naploz("Kivétel", $osszeg);
            return $osszeg;
        } else {
            throw new InvalidArgumentException("Érvénytelen kivételi összeg vagy nincs elegendő fedezet!");
        }
    }

// PUBLIC getter: az egyenleg biztonságos lekérdezése
    public function getEgyenleg(): float {
        return $this->egyenleg;
    }

// PRIVATE metódus: belső segédfüggvény, csak az osztály használja
    private function naploz(string $muvelet, float $osszeg): void {
        // Itt lehetne adatbázisba írás, fájlkezelés stb.
        $naploSor = date('Y-m-d H:i:s') . " - {$this->tulajdonos} - {$muvelet}: {$osszeg} Ft";
        // Egyszerűség kedvéért csak kiírjuk
        echo "[Napló] " . $naploSor . "<br>";
    }
}

// ------------------- Használat -------------------
$szamlam = new BankSzamla("Kiss János");
$szamlam->befizet(50000); // Működik: publikus interfészen keresztül
echo "Jelenlegi egyenleg: " . $szamlam->getEgyenleg() . " Ft<br>"; // 50000

$kivet = $szamlam->kivesz(15000); // Működik
echo "Kivett összeg: " . $kivet . " Ft<br>"; // 15000
echo "Új egyenleg: " . $szamlam->getEgyenleg() . " Ft<br>"; // 35000

// $szamlam->egyenleg = -100000; // FATAL ERROR: private tulajdonság!
// $szamlam->naploz("Csalás", 100000); // FATAL ERROR: private metódus!

?>

Miért jó ez a megközelítés? 1. Az $egyenleg nem állítható negatívra közvetlenül, mert private. 2. A pénzmozgás minden alkalommal automatikusan naplózódik a naploz() metóduson keresztül. A fejlesztőnek nem kell emlékeznie rá. 3. Az ellenőrzések (pl. pozitív összeg, fedezet) egy központi helyen, a public metódusokban történnek.

—

Gyakori Hibák és Tévhitek

1. Minden publikussá tétele („Mert így egyszerűbb”): Ez a leggyakoribb hiba. Ha egy belső segédmetódust (mint a naploz()), vagy a belső állapotot ($egyenleg) public-ra állítunk, az objektum belső konzisztenciája összeomolhat. Bárki bármikor megváltoztathatja az értékeket, megkerülve az összes beépített ellenőrzést és logikát.

2. Getter/Setter mania mindenhez: Nem minden private tulajdonsághoz kell automatikusan gettert és settert írni. Ha egy tulajdonságot „csak olvasni” lehet (mint például egy adatbázis kapcsolat leírója), írj csak gettert. Ha nincs valódi ok a változtatására, ne írj settert. A setter gyakran ugyanazt a kockázatot rejti, mintha publikus lenne a tulajdonság.

3. A private metódusok tesztelhetősége: Egy gyakori kérdés, hogy hogyan teszteljünk egy private metódust. A válasz: közvetlenül nem. Ha egy metódus annyira komplex, hogy külön tesztet igényel, az egy erős jel, hogy valójában egy külön felelősségű osztályba kellene kiszervezni, ahol public interfésze lesz. A private metódusokat a publikus metódusokon keresztül, integrációs tesztekben ellenőrizd.

4. A protected elfelejtése: Bár a cikk a public és private összehasonlítására fókuszál, fontos megemlíteni a harmadik tagot: a protected-et. Az ősosztály protected metódusai és tulajdonságai elérhetők az örökölt gyermekosztályokban is, de kívülről nem. Ha tervezel bővíteni az osztályod örökléssel, a protected a helyes választás az osztálycsalád belső logikájához.

—

Rövid Összegzés: Mikor Mit Használj?

* Használj public metódusokat az objektum szerződéséhez (*public API*). Ezek azok a műveletek, amiket az objektum nyújtani tud a külvilág felé (pl.: befizet(), kivesz(), getEgyenleg()). * Használj private metódusokat és tulajdonságokat a megvalósítás részleteihez. Ezek a kód „csontjai és inai”, amelyeket elrejtesz a felhasználó elől, hogy megvédd az objektum integritását és egyszerűsítsd a használatát (pl.: $egyenleg, naploz()). * Alapelv: Kezdetben mindent private-nak jelölj meg. Csak akkor változtasd public-ra (vagy protected-re), ha van egy kifejezett, jól megfontolt okod rá, és tisztában vagy a következményekkel.

A láthatósági módosítók helyes használata nem csupán szintaktikai szabály, hanem egy tervezési döntés. Segít elkülöníteni, *mit* csinál az objektum (publikus interfész) attól, *hogyan* csinálja (privát implementáció). Ez az elkülönítés teszi lehetővé, hogy később bátran módosítsd a belső működést anélkül, hogy megtörnéd a kódodat használó összes többi részt – ami éppen a jó OOP lényege.

Kapcsolódó cikkek