Diskuze: Velikost třídy - výkon, paměť
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Tvůrce
Zobrazeno 14 zpráv z 14.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Jedna třída by se měla starat jen o jednu věc. Jestli musíš mít v té třídě 50 metod, tak je asi něco špatně...
Mám entitu, která má několik relací na jiné entity, a jelikož projekt
není úplně malý, tak se to postupně trochu nakupilo. Možná by se dalo
něco delegovat jinam, ale velikost třídy hned nemusí znamenat porušení
SRP.
Nicméně to není odpověď na mou otázku
Atributy zabírají paměť pro každou instanci. Metody jsou kód, který sice zabírá místo v paměti, ale její velikost nezávisí na počtu instancí.
Kdyby si věděl, jak PHP zachází pamětí vnitřně, tak vůbec neřešíš, jak je tvůj objekt velký a jaký to má dopad na výkon. Takže to v PHP fakt neřeš. Koukni se, jak je naimplementované takové běžné Neasociativní pole v PHP a pochopíš, že fakt nemá smysl řešit takovéto optimalizace na úrovni tvého kódu, protože to stejně silně dojebe už PHP samo o sobě.
Tohle vůbec nemá smysl řešit, pokud tě trápí výkon, přejdi na PHP 7, které je asi 2,5x rychlejší než PHP 5. Třídu s 50 metodami bys mít neměl, protože bude asi porušovat SRP, viz - https://www.itnetwork.cz/…vrh-softwaru
Petr Homola, Marian Benčat Právě vůbec netuším, jak s tím PHP pracuje a zda je výkonnostní problém mít nějaký větší objekt. Nerad bych pak řešil problém, když by se instancí velké třídy udělalo třeba 100 během jednoho requestu. Děkuji za odpovědi!
David Hartinger Taktéž děkuji za odpověď. Výkon mě v tuto chvíli
netrápí, na PHP 7 to běží, jen bych nerad, aby později začal výkon
upadat kvůli takové kravině, jako je velký objekt Tak mě jen zajímalo, zda to
má nějaký patrný vliv.
Ohledně porušení SRP je to diskutabilní, třída je sice velká, ale stále
je to entita pracující jen se svými atributy. Navíc řada metod je spíše
pro intuitivnější použití objektu, abych např. místo
if ($item->type === "weapon" || $item->type === "armor" || $item->type === "shield")
mohl napsat
if ($item->isWeapon() || $item->isArmor() || $tem->isShield())
Tudíž si nemyslím, že by nutně SRP porušovalo, ale možné to
samozřejmě být může. Bez ukázky kódu to ale řešit moc nejde a nechce se
mi produkční kód celé třídy dávat veřejně.
Každopádně ještě jednou děkuji všem za odpověď.
Na tohle jsou návrhové vzory, ty metody isWeapon()
,
isArmor()
a podobně přeci nemusíš mít v té třídě, to je
úplně samostatná úloha něco rozlišovat Jestli jich je tam hodně,
rozdělil bych odpovědnost do další třídy a psal něco jako:
if ($item->getClassifier()->isWeapon()) // ...
nebo třeba:
if ($itemClassifier->isWeapon($item)) // ...
Záleží jak to máš napsané, co všechno se tam dělá, to musíš vědět ty
Hmm, je fakt, že hodně podobných metod je napláclých přímo v té třídě. Nicméně bych teď nerad přepisoval kus kódu, tak pokud bude později třeba, třeba se na to podívám. Díky
Právě to "později třeba" většinou již nikdy nenastane, proto by se ta odpovědnost měla rozumně přidělovat již když to člověk píše. Zrovna tahle úprava je poměrně jednoduchá, horší je to když je to něco vázané na strukturu databáze třeba.
Jsem si vědom toho, že odkládání je spíše negativní, jen se mi z
jistých důvodů nechce v tuto chvíli přepisovat fungující kód. Na
databázi to vázané je, tudíž nedokážu hned z hlavy odhadnout, jakou
práci by dalo tu třídu upravit. Osobně si nemyslím, že je to napsané
"špatně", spíš jen by to možná šlo napsat "lépe"
Jelikož to tedy nemá dopad na výkon, nechám to prozatím tak. Děkuji za
vysvětlení.
Myslel jsem to tak, že k tomu nemusíš změnit databázi. Dokud se refaktoruje jen kód, tak se to docela dá. Databáze, soubory a pod. mají obvykle více sideeffects
Jasné, už rozumím. Zde je možná trochu problém, že je to entita, která své atributy má přímo namapované na sloupce v databázi (používám ORM). Tudíž pokud bych např. "typ" předmětu delegoval na jinou třídu, musel bych obejít výchozí chování frameworku. Možná by to šlo řešit jednoduše, ale nenapadá mě v tuto chvíli jak a nerad bych teď dával čas do úprav, které by to nakonec kvůli omezení frameworku ještě mohly zhoršit
if ($item->getClassifier()->isWeapon()) // ...
šéfe kážeš o návrhových vzorech a pravidlech a hned v prvním příkladu porušíš demetera... ty ty ty
Zobrazeno 14 zpráv z 14.