Traits a jejich používání rubrika: Programování: PHP

1 frantisek.sitner
položil/-a 10.11.2016
 
upravil/-a 10.11.2016

Ahoj,

píšu knihovnu pro generování php kódu a mám třídu pro generování atributů a třídu pro generování metod a obě třídy mají atribut visibility. Abych nemusel v obou třídách psát atribut, gettery (isPublic, isProtected, isPrivate) a settery, tak jsem si pro to vytvořil Trait, který obě třídy používají.
Co si myslíte o používání Trait obecně a v tomhle konkrétním případě?
Vyřešili by jste to případně nějak jinak? Vložili by jste do nich třídu místo Traitu a delegovali na ní volání?

Díky za odpovědi.

Komentáře

  • frantisek.sitner : Jenže ty třídy už dědí od jiné, která je společná pro více tříd a tudíž tam nemá být nic o visibility. Samozřejmě by mohl být ještě společný potomek pro tyhle dvě třídy. Není na to ale Traita lepší? — 11.11.2016
  • Kit : Tak se obsah traity strčí do té rodičovské třídy a zdědí to automaticky všichni potomci. — 11.11.2016
  • Honza Břešťan : Od jake tridy uz dedi? Zalezi, jak se to modeluje, ale atributy i metody jsou oboji membery a jedna z vlastnosti memberu je access modifier ("visibility" v tomhle pripade). I kdyz normalne nejsem zastance dedicnosti, tady mi to pro potreby polymorfismu, vztahu "is-a" i code reuse celkem sedi. Pokud by bylo pridani do base class (nebo zmena hierarchie trid) neprakticke, tak bych asi volil spis kompozici a tohle volani delegoval. Traity mi prijdou vhodnejsi spis na sdileni cross-cutting funkcionality, ne na domenovou logiku. — 11.11.2016
  • frantisek.sitner : @Honza Břešťan: Když bych volil kompozici, tak v tomhle případě ale stejně napíšu(budu delegovat) všechny metody, jen nebudu psát atribut, to bude stejný kód na více místech. — 11.11.2016
  • harrison314 : Nie je v tomto pripade rozumne rienie nahradit tie gertey a setri v spoinanych triedach enumom (uz si nepametam, ci ho PHP ma), alebo instanciu triedy Visibility (ktora bude mat isPublic, isProtected, isPrivate, moze mat equals, toString,...) ? V tom pripade odpada duplicita kodu. — 11.11.2016
  • frantisek.sitner : @harrison314: A jaký je pak z tvého pohledu rozdíl mezi Traitou nebo instancí Visibility? — 14.11.2016
  • harrison314 : @frantisek.sitner: s Trait som v zivote nerobil, no podla dokumentacie to vyzera ako simulacia viacnasobnej dedicnosti, no asi tam nie je vztah "child is parent". No ak mas membre ktore suvisia s visibility, tak si zasluzia vynat do spolocnej triedy, pretoze ju mozes pouzit aj inde, moze mat vlastne metody... Toto je podla mna ukazkovy priklad na vynatie vidibity do vlastnej triedy a pouzivat ju ako member tried pouzitych v generatore. — 14.11.2016
  • harrison314 : @frantisek.sitner: Honza B. ti to rozpisal podrobne. — 14.11.2016
odkaz
9 Honza Břešťan
odpověděl/-a 14.11.2016
 
upravil/-a 14.11.2016

S malym odstupem na pochopeni toho API bych volil asi moznost nechat tridu na generovani atributu a tridu na generovani metod, at se o vygenerovani visibility staraji samy. Na jejich public rozhrani nebudou ani isPublic/isPrivate/isProtected, ani getter na nejaky objekt Visibility, ktery by ty tri metody obsahoval.

Pokud vystupem obou trid ma byt vygenerovany atribut nebo metoda, at je vygenerovany uz s visibilitou, aniz by se na ni musel volajici dotazovat explicitne. Interne si to muze ta trida resit jak chce - muze to byt skutecne nejaka instance Visibility, nebo to muze byt trait ciste pro code reuse, nebo protected metody base class. Je to jedno, protoze konzument tech trid by o tom ani nemel vedet.

Klicova myslenka pro tenhle design je vyhybani se "chatty interfaces", tzn. chci na instanci zavolat jednu vec a jen jednou, ne se s ni bavit pres nekolik method callu, abych se ja rozhodoval, co ma vlastne delat.

V hypotetickem pripade, ze treba metoda dostane nejaky novy visibility mod (treba neco jako internal/package-private), staci to pak zmenit v implementaci te tridy (nebo jeste lip v implementaci injectnute Visibility) namisto zmeny kazdeho pouziti napric vsemi projekty.

Komentáře

  • Taco : Tímhle přístupem a postupným refactoringem se dostaneš k AST :-) — 15.11.2016
  • Honza Břešťan : Kdyz se to aplikuje na vsechno, tak jo - ono taky jak jinak to obecne generovat nez traverzovanim AST. S tim refactoringem se to ale nemusi hrotit, jen mi to v tomhle pripade prijde jako moznost, jak vyresit predlozeny design problem a zaroven zjednodusit interakci mezi objekty, coz je win-win. — 15.11.2016

Pro zobrazení všech 7 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.

Aktuální otázky v rubrice Programování: PHP

Otázky uživatele frantisek.sitner