Best practice: Traity nebo dědičnost?

Tohle se musí řešit případ od případu, neexistuje univerzální odpověď.
Obecně se snažím nenadužívat dědičnost (což ještě neznamená nutně traity, ale třeba jen další službu), ale zrovna v presenterech a komponentách mi dětší než malé použití dědičnosti nevadí.

Editoval Šaman (14. 5. 2014 22:08)

Není to ani tak o tom, že bych potřeboval poradit, spíš sem chtěl podiskutovat :)

Tak nějak jsem došel k tomu, že dědičnost budu používat pokud jde o vrstvení aplikace. Extends jasně předurčuje strukturu Prarodič > Rodič > Dítě. Ty třídy tím pádem jsou jasně pod sebou. Oproti tomu Trait může být součástí klidně každé z nich, žádné takovéhle pravidlo neurčuje.

Abych uvedl příklad, na kterém jsem na to narazil. Jak už jsem říkal, jde o strukturu presenterů v modulární aplikaci. Všechny presentery dědí pochopitelně od třídy \BasePresenter – z něj vychází dvě větve: \PublicPresenter – pro veřejnou část a \SecuredPresenter – pro administrační část (CMS). Všechny dosud zmíněné presentery jsou abstraktní a předpokládá se, že jakýkoliv presenter v aplikaci bude dědit od Public nebo Secured.

Pak jsem pokračoval hlouběji do zabezpečené sekce: většina modulů, jako asi v každé aplikaci, používá dejme tomu tři základní funkčnosti: Seznam položek, Formulář (insert/edit) a Řazení položek, přičemž se mění jen Formulář a název entity se kterou se pracuje (každá entita pak má standartně vlastnosti id, title, active a priority – které se použijí pro defaultní Seznam).

Celou tuhle logiku řazení, výpisů a ukládání pak ovládá nějaký presenter, můžeme ho pojmenovat třeba Admin\DefaultPresenter, a jak už bylo řečeno v předchozím odstavci, tahle logika se opakuje napříč mnoha presentery v různých modulech. V tomto případě se mi líbí použít víc trait, protože nejde říct, že by presenter Admin\NewsPresenter, který obsluhuje novinky a dělá přesně to samé co Admin\DefaultPresenter, nějakým způsobem ležel pod ním. To, že sdílí nějakou funkčnost nevidím jako to, že by leželi pod sebou – podle mě jsou vedle sebe. Čili trait :)

Jako komponenty jsou jednoznačně jednotlivé bloky toho presenteru: řazení položek, tabulkový výpis, formulář… Furt bych je ale rád měl zabalené v jednom balíku, čistě z toho důvodu, že je to pohodlné. Dali by se includovat přes use jedna po druhé, ale mnohem raději bych to měl v jediném příkazu.

Nějak si nedovedu představit, že by to všechno bylo obalené zrovna v komponentně (asi to bude nedostatkem znalostí :P byl bych vděčný za příklad z praxe). Zatím jsem nenarazil na žádné nedostatky toho, mít ten „balík“ jako presenter. Pokud potřebuji nějaké součásti vyměnit (zpravidla tvoření formuláře a jeho uložení), stačí přetížit příslušné metody zodpovědné za vytvoření a zpracování formuláře.

Editoval mirimCZ (15. 5. 2014 12:33)