Property Hooks v PHP 8.4: Revoluce nebo Past?

Představte si, že by vaše PHP objekty mohly být čistší, přehlednější a lépe použitelné. Dobrá zpráva – už nemusíte snít! PHP 8.4 přichází s revoluční novinkou v podobě property hooks a asymetrické viditelnosti, které kompletně mění pravidla hry v objektově orientovaném programování. Zapomeňte na neohrabané gettery a settery – konečně máme k dispozici moderní a intuitivní způsob, jak kontrolovat přístup k datům objektů. Pojďme se podívat na to, jak tyto novinky mohou změnit váš kód k nepoznání.

Property hooks představují promyšlený způsob, jak definovat chování při čtení a zápisu vlastností objektu – a to mnohem čistěji a výkonněji než dosavadní magické metody __get/__set. Je to jako byste dostali k dispozici sílu magických metod, ale bez jejich typických nevýhod.

Podívejme se na jednoduchý příklad z praxe, který vám ukáže, proč jsou property hooks tak užitečné. Představme si běžnou třídu Person s veřejnou property age:

class Person
{
	public int $age = 0;
}

$person = new Person;
$person->age = 25;  // OK
$person->age = -5;  // OK, ale to je přece nesmysl!

PHP sice díky typu int zajistí, že věk bude celé číslo (to lze od PHP 7.4), ale co s tím záporným věkem? Dříve bychom museli sáhnout po getterech a setterech, property by musela být private, museli bychom doplnit spoustu kódu… S hooks to vyřešíme elegantně:

class Person
{
	public int $age = 0 {
		set => $value >= 0 ? $value : throw new InvalidArgumentException;
	}
}

$person->age = -5;  // Ups! InvalidArgumentException nás upozorní na nesmysl

Krása tohoto řešení spočívá v jeho jednoduchosti – navenek se property chová úplně stejně jako dřív, můžeme číst i zapisovat přímo přes $person->age. Ale máme plnou kontrolu nad tím, co se při zápisu děje. A to je teprve začátek!

Můžeme jít ještě dál a vytvořit třeba hook pro čtení. Hookům lze přidat atributy. A samozřejmě mohou obsahovat složitější logiku než jednoduchý výraz. Podívejte se na tento příklad práce se jménem:

class Person
{
	public string $first;
	public string $last;
	public string $fullName {
		get {
			return "$this->first $this->last";
		}
		set(string $value) {
			[$this->first, $this->last] = explode(' ', $value, 2);
		}
	}
}

$person = new Person;
$person->fullName = 'James Bond';
echo $person->first;  // vypíše 'James'
echo $person->last;   // vypíše 'Bond'

A něco důležitého: kdykoliv se přistupuje k proměnné (i uvnitř samotné třídy Person), vždy se využijí hooks. Jediná výjimka je přímý přístup k reálné proměnné uvnitř kódu samotného hooku.

Ohlédnutí do minulosti: Co nás naučil SmartObject?

Pro uživatele Nette může být zajímavé ohlédnout se do minulosti. Framework totiž podobnou funkcionalitu nabízel už před 17 lety ve formě SmartObject, který výrazně vylepšoval práci s objekty v době, kdy PHP v této oblasti značně zaostávalo.

Pamatuju si, že tehdy přišla vlna bezbřehého nadšení, kdy se properties používaly prakticky všude. Tu pak vystřídala vlna opačná – nepoužívat je nikde. Důvod? Chybělo jasné vodítko, kdy je lepší použít metody a kdy property. Ale dnešní nativní řešení je kvalitativně úplně jinde.Property hooks a asymetrická viditelnost jsou plnohodnotné nástroje, které nám dávají stejnou úroveň kontroly jako máme u metod. Proto dnes můžeme mnohem lépe rozlišit, kdy je property skutečně tím správným řešením.

Backed nebo Virtual? Dobrá otázka!

Podívejte se na tento kód a zkuste si rychle odpovědět – je to vlastně jednoduchý kvíz:

• Můžeme do $age zapisovat?
• A co $adult – můžeme číst i zapisovat?

class Person
{
	public int $age = 0 {
		set => $value >= 0 ? $value : throw new InvalidArgumentException;
	}

	public bool $adult {
		get => $this->age >= 18;
	}
}

Samozřejmě $age je, jak jsme si řekli už dříve, property pro čtení i pro zápis. Ale $adult je jen pro čtení!

A tady narážíme na první zapeklitost v designu property hooks. Ze signatury property vůbec nepoznáme, jestli do ní můžeme zapisovat nebo ji číst!

Odpověď se totiž skrývá v kódu, v implementaci hooků. Property totiž mohou být dvojího druhu: backed (se skutečným úložištěm v paměti) a virtuální (které pouze simulují existenci property). To, zda je property backed nebo virtuální, rozhoduje, zda se v kódu hooku na ni odkazujeme.

Property je backed (má vlastní úložiště), když:

• v těle hooku se na ni odkazujeme přes $this->propertyName
• nebo má zkrácený set, který automaticky znamená zápis do $this->propertyName

V našem příkladu tedy:

• Property $age je backed, protože používá zkrácený set (což automaticky znamená zápis do $this->age)
• Property $adult je virtuální, protože žádný její hook neobsahuje $this->adult

Je to sice mazané řešení, ale ne zrovna šťastné. Tak zásadní informaci, jako zda lze property číst nebo do ní zapisovat, má prozradit API a signatura na první pohled, ne až studium implementace.

Když reference, tak bezpečně!

Reference existují v PHP od jeho počátků. Pomocí znaku & můžete propojit dvě proměnné tak, aby ukazovaly na stejné místo v paměti. Je to jako mít dva dálkové ovladače k jedné televizi – ať zmáčknete kterýkoliv, ovládáte tu samou obrazovku.

Ale co kdyby někdo mohl získat referenci na property s set hookem? Mohl by její hodnotu měnit přímo a kompletně tak obejít veškerou validaci. Podívejte se na tento příklad:

class Person
{
	public int $age = 0 {
		set => $value >= 0 ? $value : throw new InvalidArgumentException;
	}
}

$person = new Person;
$ref = &$person->age;    // Fatal error: Tohle neprojde!
$ref = -5;               // Kdyby to prošlo, validace by byla k ničemu

PHP na to myslelo a elegantně to vyřešilo (tedy pardon, mysleli na to Ilija Tovilo a Larry Garfield, autoři hooků). Získat referenci na takovou property prostě není možné (myšleno na backed proměnnou se set hookem). Je to správné řešení – property hook má zajistit, že se do property dostane jen platná hodnota, a reference by tuto kontrolu obcházely.

Když pole potká property hooks – zajímavá výzva!

Práce s poli v PHP je obvykle příjemně přímočará. Do pole v property můžeme přidávat prvky různými způsoby:

class Person
{
	public array $phones = [];
}

$person = new Person;
$person->phones[] = '777 123 456';          // přidá číslo na konec pole
$person->phones['bob'] = '777 123 456';     // přidá číslo s konkrétním klíčem

A právě tady narážíme na zajímavý problém s property hooks. Představme si, že chceme vytvořit třídu Person, která bude obsahovat seznam telefonních čísel, a chceme, aby se u nich automaticky ořezávaly mezery na začátku a konci:

class Person
{
	public array $phones = [] {
		set => array_map('trim', $value);
	}
}

$person = new Person;
$person->phones[] = '777 123 456';  // Překvapení! Error: Indirect modification of Person::$phones is not allowed

Proč to nefunguje? Operace $person->phones[] totiž v PHP funguje ve dvou krocích:

1. Nejdřív získá referenci na pole pomocí get
2. Pak do získaného pole přidá novou hodnotu

Tedy vůbec se nevolá set hook. Ba co víc, jak už víme z předchozí kapitoly, nelze získat referenci na backed proměnnou se set hookem (tedy udělat první krok). Proto ta chybová hláška.

Ani metoda addPhone(), která by volala $this->phones[] = $phone, nám nepomůže – všechny přístupy k property (i uvnitř třídy) totiž procházejí přes hooky.

Tak jak z toho ven? Pojďme si projít možná řešení. První, které vás možná napadne:

$phones = $person->phones;    // načteme pole
$phones[] = ' 777 123 456 ';  // přidáme číslo
$person->phones = $phones;    // uložíme zpět

Funguje to, ale… představte si pole s tisíci čísly. Náš set hook by musel provést trim() na všech číslech znovu, i když se přidalo jediné. To není zrovna ukázka efektivity.

Existuje lepší cesta – uvědomit si, že pokud má pole nějak specificky pracovat se svými prvky (třeba ořezávat mezery), mělo by to být jeho zodpovědností, ne úkolem třídy, která ho jen drží. Jasně, pole samo o sobě nenaučíme novým trikům, ale můžeme ho „zabalit“ do objektu s rozhraním ArrayAccess:

class Phones implements ArrayAccess
{
	private array $data = [];

	public function __construct(array $data = [])
	{
		$this->data = array_map('trim', $data);
	}

	public function offsetSet(mixed $offset, mixed $value): void
	{
		$value = trim($value);
		if ($offset === null) {
			$this->data[] = $value;
		} else {
			$this->data[$offset] = $value;
		}
	}

	// implementace dalších metod pro ArrayAccess...
}

class Person
{
	function __construct(
		public Phones $phones = new Phones,
	) {}
}

$person = new Person;
$person->phones[] = ' 777 123 456 ';  // Hurá! Číslo se uloží pěkně ořezané

A teď třešnička na dortu – můžeme využít hook k tomu, aby do $person->phones šlo zapsat i obyčejné pole:

class Person
{
	function __construct(
		public Phones $phones = new Phones {
			set(array|Phones $value) => is_array($value) ? new Phones($value) : $value;
		},
	) {}
}

$person = new Person;
$person->phones = ['  888 999 000  ', '777 888 999'];  // Magicky se převede na Phones a ořeže řetězce

Jak vidíte, hooks mohou obsahovat i promoted properties.

Ještě se podívejme na alternativní řešení. Vzpomeňte si, že kromě backed property máme ještě virtuální property – ty, které nepoužívají $this->propertyName v těle hooku. A tady se skýtá druhé řešení:

class Person
{
	private array $_phones = []; // skutečné úložiště čísel

	public array $phones {  // virtuální property pro veřejný přístup
		get => $this->_phones;
		set {
			$this->_phones = array_map('trim', $value);
		}
	}

	public function addPhone(string $phone): void
	{
		$this->_phones[] = trim($phone);
	}
}

$person = new Person;
$person->addPhone(' 777 123 456 ');  // Přidá ořezané číslo
echo $person->phones[0];             // Vypíše "777 123 456"
$person->phones = ['  888 999 000  ']; // Nastaví nové pole s ořezanými čísly

Tady jsme zůstali u klasického pole, ale schovali jsme ho za privátní proměnnou. Na venek nabízíme virtuální property pro čtení celého pole a jeho kompletní přepsání, plus specializovanou metodu pro přidávání jednotlivých čísel.

Hooks a dědičnost: Když potomci přebírají žezlo

Potomci mohou nejen přidávat hooks k vlastnostem, které je dosud neměly, ale také předefinovat ty existující. Podívejme se na příklad:

class Person
{
	public string $email;

	public int $age {
		set => $value >= 0
			? $value
			: throw new InvalidArgumentException('Věk nemůže být záporný');
	}
}

class Employee extends Person
{
	// Přidá hook k vlastnosti, která žádný neměla
	public string $email {
		set => strtolower($value);  // Emaily vždy převedeme na malá písmena
	}

	// Rozšíří existující validaci věku
	public int $age {
		set => $value <= 130
			? parent::$age::set($value)  // Nejdřív ověříme původní podmínku
			: throw new InvalidArgumentException('130 let? Tomu nevěřím!');
	}
}

Všimněte si té zajímavé syntaxe parent::$age::set($value). Na první pohled možná vypadá zvláštně, ale dává perfektní smysl – nejdřív se odkážeme na vlastnost v rodiči a pak na její hook. Je to jako bychom řekli „hej, zavolej set hook na age vlastnosti mého rodiče“.

A co víc – můžeme hooks označit jako final, pokud chceme zabránit jejich přepsání v potomcích. Dokonce můžeme jako final označit celou property – pak ji potomci nemohou změnit žádným způsobem (ani přidat hooks, ani rozšířit její viditelnost).

class Person
{
	// Tenhle hook už nikdo nepřepíše
	public int $age {
		final set => $value >= 0 ? $value : throw new InvalidArgumentException;
	}

	// A tuhle property už vůbec nikdo nezmění
	final public string $id;
}

Property v rozhraních

Překvapivou novinkou je podpora property v rozhraních a abstraktních třídách. Představte si, že vytváříte rozhraní pro entity, které obsahují řetězec se jménem. Doteď jsme museli psát něco takového:

interface Named
{
	public function getName(): string;
	public function setName(string $name): void;
}

Nuda, že? S property hooks můžeme být mnohem elegantnější! V rozhraní teď můžeme deklarovat přímo property, a to dokonce asymetricky – můžeme říct zvlášť, co má být čitelné a co zapisovatelné:

interface Named
{
	// Říkáme: "Implementující třída musí mít veřejně čitelnou property name"
	public string $name { get; }
}

A teď to zajímavé – jak můžeme takové rozhraní implementovat? Máme hned několik možností:

class Person implements Named
{
	public string $name;     // Nejjednodušší řešení - obyčejná property
}

class Employee implements Named
{
	public string $name {    // Pokročilejší - složené jméno
		get => $this->firstName . ' ' . $this->lastName;
	}
	private string $firstName;
	private string $lastName;
}

Všimněte si zajímavého detailu – rozhraní Named požaduje property pouze pro čtení, ale třída Person nabízí property čitelnou i zapisovatelnou. A to je naprosto v pořádku – rozhraní totiž definuje jen minimální požadavky. Je to jako když řeknete „potřebuju auto, co jede dopředu“ a dostanete auto, co umí i couvat – splňuje to vaše minimální požadavky a přidává něco navíc.

Pro puntičkáře: V rozhraní musíme u property použít klíčové slovo public, i když je to vlastně nadbytečné – vše v rozhraní je ze své podstaty veřejné. U metod uvádět public je hloupost, ale u property je to vyžadováno kvůli konzistenci syntaxe.

A ještě jedna věc stojí za zmínku – všimli jste si té zvláštní syntaxe { get; set; }? Zatímco ve třídě můžeme napsat jednoduše public string $name, v rozhraní musíme explicitně říct, jaké operace property podporuje. Je to sice trochu pracnější, ale dává to smysl – u rozhraní chceme být maximálně explicitní v tom, co požadujeme.

Property v abstraktních třídách: To nejlepší z obou světů

Abstraktní třídy si vezmou to nejlepší z rozhraní a přidají vlastní šťávu. Mohou nejen deklarovat property, ale také nabídnout výchozí implementaci některých hooků:

abstract class Person
{
	// Čistě abstraktní property - implementaci dodá potomek
	abstract public string $name { get; }

	// Protected property s oběma operacemi
	abstract protected int $age { get; set; }

	// Tady už nabízíme hotovou validaci emailu
	abstract public string $email {
		get; // tento hook je abstraktní a potomek ho musí implementovat
		set => Nette\Utils\Validators::isEmail($value)
			? $value
			: throw new InvalidArgumentException('Tohle nevypadá jako email...');
	}
}

A teď něco opravdu zajímavého – kovarianci a kontravarianci!

Zní to jako zaklínadlo, ale je to vlastně jednoduchá věc. Podívejte se:

class Animal {}
class Dog extends Animal {}

interface PetShop
{
	// Property jen pro čtení může vracet specifičtější typ
	public Animal $pet { get; }
}

class DogShop implements PetShop
{
	// Vrací psa místo zvířete - to je v pohodě!
	public Dog $pet { get; }
}

Když má property pouze hook get, může v potomkovi vracet specifičtější typ (tomu se říká kovariance). Představte si to jako: „Slíbil jsem ti zvíře, a pes je přece taky zvíře, ne?“

Naopak property pouze s hookem set může v potomkovi přijímat obecnější typ (kontravariance). Je to logické – když umím pracovat s konkrétním typem, zvládnu i jeho předka.

Jakmile má property oba hooky get i set, musí typ zůstat stejný. Proč? Protože by to mohlo vést k nekonzistencím – nemůžeme slíbit, že vrátíme psa, když nám někdo může přes setter podstrčit kočku!

Asymetrická viditelnost: Každému, co jeho jest

Představte si, že vytváříte třídu Person a chcete, aby datum narození mohl číst kdokoliv, ale měnit ho mohla jen samotná třída. Dřív byste museli sáhnout po getterech a setterech, ale teď? Teď máme elegantní řešení:

class Person
{
	public private(set) DateTimeImmutable $dateOfBirth;
}

Tenhle zápis říká: „Číst může každý, zapisovat jen třída sama.“ První modifikátor public určuje viditelnost pro čtení, druhý private(set) pro zápis. A protože veřejné čtení je default, můžeme ho vynechat a psát prostě:

class Person
{
	private(set) DateTimeImmutable $dateOfBirth;
}

Samozřejmě platí logické pravidlo – viditelnost pro zápis nemůže být širší než pro čtení. Nemůžeme použít třeba protected public(set) – to by bylo jako říct „číst můžou jen potomci, ale zapisovat může každý“. Trochu podivné, ne?

A co dědičnost? V PHP platí, že potomek může viditelnost buď zachovat, nebo rozšířit z protected na public. To samé platí i pro asymetrickou viditelnost:

class Person
{
	public protected(set) string $name;  // Číst může každý, zapisovat jen potomci
}

class Employee extends Person
{
	public public(set) string $name;     // Potomek může rozšířit práva zápisu
}

Zajímavý je případ private(set). Taková property je automaticky final – když řekneme, že zapisovat může jen třída sama, logicky to znamená, že ani potomci nemají právo to měnit.

A nejlepší na tom je, že asymetrickou viditelnost můžeme kombinovat s hooks:

class Person
{
	private(set) DateTimeImmutable $birthDate {
		set => $value > new DateTimeImmutable
			? throw new InvalidArgumentException('Narození v budoucnosti? Sci-fi!')
			: $value;
	}
}

Tahle property má všechno: je veřejně čitelná, zapisovat do ní může jen třída sama, a ještě kontroluje, jestli datum není v budoucnosti. Hooks řeší „co se má stát“, asymetrická viditelnost „kdo to může udělat“. Perfektní tým!

Asymetrická viditelnost a pole: Elegantní řešení starého problému

Pamatujete na naše trápení s telefonními čísly? Asymetrická viditelnost nám nabízí ještě jedno řešení:

class Person
{
	private(set) array $phones = [];

	public function addPhone(string $phone): void
	{
		$this->phones[] = trim($phone);
	}
}

$person = new Person;
var_dump($person->phones);     // OK: můžeme číst
$person->addPhone('...');      // OK: můžeme přidat číslo
$person->phones = [];          // CHYBA: nemůžeme přepsat celé pole

Pole je veřejně čitelné, ale nikdo zvenčí ho nemůže přepsat. Pro přidání nového čísla máme specializovanou metodu. Žádné složité objekty simulující pole, žádné virtual properties – jen čistá, jasná kontrola přístupu.

Pro úplnost dodejme, že u vlastnosti s omezeným zápisem nemůžete získat referenci zvenku:

$ref = &$person->phones;    // Fatal error: Takhle ne!

Reference jsou povolené jen ze scope, ze kterého je property zapisovatelná. Je to logické – reference by mohla obejít naše omezení pro zápis.

Když to shrneme, pro práci s polem v property máme teď několik možností:

1. Chytrý objekt simulující pole (přináší víc možností, ale taky víc kódu)
2. Backed property s hookem (znemožňuje přímou modifikaci pole)
3. Virtual property s privátním úložištěm (vyžaduje metody pro úpravy)
4. Asymetrická viditelnost (přesouvá logiku do metod)

Který přístup vybrat? Jak už to bývá – záleží na konkrétním případu. Prostě si zkusit, které API nejlépe sedne do ruky.

Readonly a asymetrická viditelnost: Konečně svoboda volby!

Modifikátor readonly jsou ve skutečnosti dva modifikátory v jednom: zakazuje vícenásobný zápis a zároveň omezuje zápis na private. Vlastně to není žádný readonly, je to spíš writeonce zkřížený s private(set).

To druhé mi přišlo vždy zbytečně přísné a nepraktické. Proč by readonly vlastnost nemohla být zapisovatelná třeba v potomcích?

PHP 8.4 to konečně změnilo. Teď readonly dělá property defaultně protected(set), tedy zapisovatelnou i v potomcích. A když potřebujeme jinou viditelnost? Jednoduše si ji nastavíme:

class Person
{
	// Readonly přístupná jen uvnitř třídy (staré chování)
	public private(set) readonly string $name;

	// Readonly přístupná i v potomcích (nové výchozí chování)
	public readonly string $dateOfBirth;

	// Readonly zapisovatelná kdekoliv (ale jen jednou!)
	public public(set) readonly string $id;

	public function rename(string $newName): void
	{
		$this->name = $newName;    // Uvnitř třídy můžeme měnit
	}
}

class Employee extends Person
{
	public function setBirthDate(DateTimeImmutable $date): void
	{
		$this->dateOfBirth = $date;  // V potomkovi můžeme měnit
	}
}

$person = new Person;
$person->id = 'abc123';     // Tohle projde
$person->id = 'xyz789';     // Ale tohle už ne - readonly!

Což nám dává přesně tu flexibilitu, kterou potřebujeme.

Když si terminologie protiřečí…

Pojďme se podívat na malý terminologický zmatek v PHP:

• Pořád mluvíme o čtení a zápisu vlastností
• Máme modifikátor readonly
• V phpDoc najdeme anotace @property-read a @property-write
• Ale v hooks a asymetrické viditelnosti najednou používáme get/set

Bylo by logičtější používat termíny read a write, ne?

U hooks bych ještě pochopil použití get/set – jde o akce a navíc to navazuje na magické metody __get/__set. Ale u asymetrické viditelnosti? To je přece koncepčně odlišná věc – neřeší „co se má stát“ jako hooks, ale „kdo to může udělat“. Proto by dávalo mnohem větší smysl použít termín write, tedy například private(write):

class Person
{
	private(set) string $name;     // takhle to je
	private(write) string $name;   // takhle by to dávalo větší smysl
}

Druhá varianta by byla mnohem intuitivnější. Navíc by lépe ladila s existujícím modifikátorem readonly.

Vypadá to, že PHP ve snaze o syntaktickou konzistenci mezi hooks a asymetrickou viditelností obětovalo sémantickou konzistenci s již existujícími koncepty v jazyce.

Nová éra v PHP: Revoluce v objektovém návrhu

V PHP světě jsme byli dlouho odkázáni na jediný správný způsob objektově orientovaného návrhu: všechny vlastnosti private a přístup k nim výhradně přes gettery a settery. Nebyla to rozmazlenost vývojářů – public property prostě byly problematické:

• Každý do nich mohl strkat nos bez jakékoliv kontroly
• Byly součástí veřejného API, takže každá změna (třeba přidání validace) znamenala rozbití zpětné kompatibility
• V rozhraních jste je mohli tak akorát zmínit v komentářích

Kdo chtěl programovat správně, používat rozhraní a dependency injection, musel sáhnout po getterech a setterech. Byla to jediná cesta, jak mít plnou kontrolu nad tím, co se v objektech děje.

Ale s PHP 8.4 přichází nová doba! Property hooks a asymetrická viditelnost nám konečně dávají nad vlastnostmi stejnou kontrolu jako nad metodami. Property se stávají plnohodnotnou součástí veřejného API, protože:

• Kdykoliv můžeme přidat validaci nebo transformaci hodnot
• Máme pod palcem, kdo může hodnoty měnit
• Můžeme je deklarovat v rozhraních

V podstatě můžete property hooks brát jako elegantní náhradu getterů a setterů bez zbytečného boilerplate kódu. Nebo naopak – gettery a settery byly jen takové provizorní řešení, než PHP dospělo k něčemu lepšímu.

Ze své vlastní zkušenosti s Nette můžu mluvit velmi konkrétně – jak jsem říkal, framework podobnou funkcionalitu nabízel už před 17 lety. To znamená, že jsem měl možnost s property přístupem pracovat dlouho. A musím říct, že to bylo nesmírně návykové. Porovnejte:

// Starý svět
$this->getUser()->getIdentity()->getName()

// Nový svět
$this->user->identity->name

Druhý zápis není jen kratší a čitelnější – je taky přirozenější. Je to jako rozdíl mezi „Prosím, mohli byste mi laskavě podat informaci o vašem jméně?“ a normálním „Jak se jmenuješ?“.

Jasně, možná namítnete, že přímý přístup k datům může svádět k porušování principů objektově orientovaného návrhu. Že místo ptaní se objektu na data bychom ho měli požádat o akci (Tell-Don't-Ask). To je pravda – ale hlavně pro objekty s bohatým chováním, které implementují business logiku. Pro datové transfer objekty, value objects nebo konfigurační třídy je přímý přístup k datům naprosto přirozený.

Zároveň nám tu vzniká pořádné dilema. Co s existujícími projekty? Pokud máte knihovnu nebo framework, který důsledně používá gettery a settery, bylo by možná kontraproduktivní do něj najednou zavádět property. Rozbili byste tím konzistenci API – uživatel by musel hádat, kde použít metodu a kde vlastnost.

Časem se určitě vytvoří nové styly a konvence. Některé projekty možná zůstanou u getterů a setterů, jiné budou hledat cesty jak začlenit property. Hlavně že máme na výběr.

Důležité je i pojmenování

Jak vlastně property pojmenovat? Zejména u boolean hodnot to není tak přímočaré, jak by se mohlo zdát.

U metod se běžně používají prefixy is nebo has:

class Article {
	public function isPublished(): bool { ... }
	public function hasComments(): bool { ... }
}

Ale u properties by tyto prefixy působily krkolomně a redundantně. Místo nich je lepší používat přídavná jména nebo podstatná jména:

class Article {
	public bool $published;     // lepší než $isPublished
	public bool $commented;     // lepší než $hasComments
	public bool $draft;         // lepší než $isDraft
}

if ($article->published) {      // čte se přirozeně
	// ...
}

Pro počty položek je lepší použít množné číslo:

class Article {
	public int $views;          // lepší než $viewCount
	public array $tags;         // jasně říká, že jde o kolekci
}

Jde o to, aby kód byl čitelný jako běžná věta. Když píšeme if ($article->published), čte se to mnohem přirozeněji než if ($article->isPublished). Property by měly vypadat jako vlastnosti, ne jako zapomenuté závorky u metody.

Kdy použít property a kdy metody?

Výborná otázka! Tady si můžeme vzít inspiraci z jazyků jako C# nebo Kotlin, které s property pracují už roky. Property se skvěle hodí pro:

Value objects a DTO:

class Money {
	public readonly float $amount;
	public readonly string $currency;
}

Jednoduché entity:

class Article {
	public string $title;
	public string $content;
	public DateTimeImmutable $publishedAt;
	public bool $published {
		get => $this->publishedAt <= new DateTimeImmutable;
	}
}

Computed hodnoty závislé na jiných vlastnostech:

class Rectangle {
	public float $width;
	public float $height;
	public float $area {
		get => $this->width * $this->height;
	}
}

Metody jsou lepší pro:

• operace pracující s více property najednou
• operace s vedlejšími efekty (logování, notifikace)
• akce, které něco dělají (save, send, calculate…)
• komplexní validace nebo business logiku
• operace, které mohou selhat z více důvodů
• situace, kde oceníme fluent interface

Všechna tato doporučení se nám snaží říct jednu základní věc: za použitím property by se neměl skrývat žádný složitý proces nebo něco, co má vedlejší efekty. Složitost operace by měla zhruba odpovídat tomu, co intuitivně očekáváme od čtení či zápisu do proměnné.

I když… vzpomeňte si na innerHTML v JavaScriptu. Když napíšete element.innerHTML = '<p>Ahoj</p>', spustí se složitý proces parsování HTML, vytvoření DOM stromu, překreslení stránky… A přesto to všichni považují za přirozené!

Takže možná důležitější než samotná složitost implementace je to, jestli daná operace _konceptuálně_ odpovídá vlastnosti. Je to jako s autem – tlačítko start/stop může spustit složitou sekvenci kroků, ale pro řidiče je to pořád jen „zapnout/vypnout“.