A property hooks az egyik legkényelmesebb újítás a PHP 8.4-ben, de nem minden gettert érdemes lecserélni rá. Megnézzük, hol nyersz vele, és hol csak divatból írnád át a kódot.
A PHP 8.4 property hooks funkciója lehetővé teszi, hogy egy tulajdonság olvasásához vagy írásához logikát kössünk anélkül, hogy külön getter és setter metódust írnánk. Első ránézésre ez csak kevesebb gépelés, de van, ahol tényleg jobb kódot eredményez, és van, ahol nem.
Mit vált ki?
A klasszikus minta: privát tulajdonság, mellé egy getter, ami számol valamit. A hívó oldalon ez metódushívás. A property hook ugyanezt tulajdonságként engedi elérni, a logika viszont ott marad az osztályban.
A gyakorlati előny nem a rövidség, hanem hogy a hívó kód nem árulja el, számított értékről vagy tárolt mezőről van-e szó. Ez azt jelenti, hogy egy tárolt mezőt később számítottá alakíthatsz anélkül, hogy minden hívási helyet át kellene írni.
Hol éri meg?
- Származtatott értékeknél, amelyek mindig a többi mezőből következnek: teljes név, bruttó ár, hátralévő napok száma.
- Validációnál íráskor, ha egy mező nem vehet fel akármilyen értéket, és ezt az osztály maga akarja garantálni.
- Értékobjektumoknál, ahol a cél pont az, hogy az adat és a rá vonatkozó szabály egy helyen legyen.
Hol nem?
Ha a getter drága műveletet végez (adatbázis-lekérdezést, HTTP-hívást, fájlolvasást), akkor a metódus a jobb választás. Egy tulajdonság olvasása azt sugallja, hogy olcsó. Ha valójában nem az, a következő fejlesztő ciklusban fogja olvasni, és nem érti majd, miért lassú az oldal.
Ugyanígy nem érdemes hozzányúlni a működő Eloquent-modellekhez sem. A Laravel accessor és cast rendszere jól bevált, és szorosan illeszkedik az Eloquent modellek attribútumkezeléséhez és szerializációjához; a property hook ezeket nem váltja ki, csak összekavarja a képet.
Mit csinálnék helyetted
Új kódnál nyugodtan használd ott, ahol a fenti három eset valamelyike igaz. Meglévő kódbázison viszont ne indíts refaktorálást pusztán emiatt: a gettereket lecserélni önmagában nem javít semmit, viszont minden módosítás kockázat, és a code review-t is megnehezíti.
A jó szabály: a nyelv új eszközét akkor vezesd be, amikor egy konkrét problémát old meg, nem akkor, amikor megjelenik.
