Ziskavanie vlastnosti v triede bez instancie – PHP – Fórum – Programujte.com

Ahojte,

potreboval by som poradit s nejakym elegantnym riesenim problemu, s ktorym si neviem rady. Som zaciatocnik v OOP.

Mam triedu v ktorej mam definovane vlastnosti a kvoli zapuzdreniu maju modifikatory private (alebo protected). Data z nich si upravujem a ziskavam getermi a setermi.

Avsak, niekedy potrebujem v inej triede zistit ich (defaultny) obsah, ale nechcem (nemozem) triedu instancovat. Zatial som vymyslel len sposob statickou metodou, ktora je vnutri danej triedy a pomocou get_class_vars ich vytiahnem a vratim triede ktora ich ziada (tam data rozparsujem).

Ale to je podla mna prasacina :( .. Nic ine ma vsak uz nenapadlo. Vy sikovnejsi, ako by ste k tomu pristupili vy?

#1 majo
Pokud potřebuješ pracovat s atributy třídy (nikoli instance), tak k tomu je přímo určen "static".

Na druhé straně popisovaná funkcionalita mi "silně smrdí". To nemůžeš využít normální instance s využitím nějakého polymorfismu? To se skutečně potřebuješ patlat s reflexí, když to jde i bez ní kratším a rychlejším kódem a s menšími problémy?

#2 Kit
ano, aj mne smrdi, ale neviem sa s toho vymotat..

skusim popisat co riesim:

1. Trieda Entita - obsahuje len vlastnosti v ktorych su zapisane urcite data + getery a setery (ktore zdedi od inej abstraktnej triedy) - cize schranka na data

2. Trieda EntityManager - trieda ktora spravuje vsetky Entity.. napr. find('NazovTriedyEntity', 'vlastnostEntity', 'hodnota').. v tejto triede by som napr. potreboval overit ci vlastnostEntity existuje v NazovTriedyEntity - cize manazer schranok

3. Trieda Select - tato trieda zozenie data na zaklade 'NazovTriedyEntity', 'vlastnostEntity', 'hodnota' (a znova predtym potrebuje jej vlastnosti) a az teraz vytvori Instanciu Entita podla NazovTriedyEntity (alebo pole instancii podla poctu dat), do ktorej ziskane data "hydratuje".. - jeho ulohou je plnit entity (aj ked toto by mohol robit tiez EntityManager)

Teda:

$entita = $entityManager->find('NazovTriedyEntity', 'vlastnostEntity', 'hodnota'); // poziada Select o naplnene entity

$entita->setVlastnost; $entita->getVlastnost;

Neviem preto, ci by bolo spravne volat instanciu schranky (Entitu), len preto aby som ziskal jej vlastnosti a potom ju zahadzovat.. Bohuzial aj EntityManager aj Select si potrebuju niekedy overit vlastnost Entity este pred jej instancovanim.. proces ziskavania dat je totiz narocny nato, aby prebehol zbytocne ak data nebudu sediet..

uz som to prepisal asi 5x a furt neviem prist na aspon trochu "cisty" sposob.. 

#3 majo
Problém je v tom, že se snažíš třídu Entita dělat jako univerzální. Podle popisu ji máš zcela anemickou. Mnohem lepšího výsledku bys dosáhl, kdybys místo ní použil array(). Tím by odpadly všechny zbytečné gettery/settery.

Kromě toho se v PHP gettery a settery píší jinak. Podívej se na metody __get() a __set(), které to mají v popisu práce. Používá se to podobně jako properties v C#.

EntityManager mi také připadá jako hloupost. Proč se ptát nějakého manažera, když se můžeš zeptat objektu? Vždy, když zahlédnu slovo Manager, tak vím, že to s OOP nemá mnoho společného.

Místo třídy Select by ve tvých objektech mohla být metoda select(), která by ti stejnou službu zvládla mnohem lépe a přehledněji.

Tedy místo 

find('NazovTriedyEntity', 'vlastnostEntity', 'hodnota')

napíšeš mnohem jednodušší 

$entita->find('hodnota')

a dá se to zjednodušit ještě víc, když důvod toho hledání strčíš přímo do metody objektu $entita.

Tohle je OOP.

to bolo len na konkretnu ukazku, Manager spracovava samozrejme podstatne viac roznych druhov operacii v entitach (CRUD), nie len jednoduche "find", preto som chcel tuto ulohu zverit iba jemu (zistit co najst, co zmazat, co editovat...).. Select ma tiez viac sposobov ako hlada data (on zisti kde to najst a ziska to), ak ich nenajde, tak zase ziada dalsiu triedu o ich vytvorenie.. + su tam dalsie triedy ako DELETE atd..

je to pomerne komplexne, a preto su ulohy takto rozdelene.. v podstate ide o obdobu ORM.. nie je tak jednoducha ako v priklade..

Entita by mala byt v samostatnej triede (a subore) kvoli prehladnosti, tiez ich bude pomerne dost.. Entita nevie nic o sebe, ta len nosi svoje vlastnosti.. nevie kde su data

getery setery samozrejme volam getVlastnost a setVlastnost('nova vlastnost')..

takto som bol nauceny, ze ulohy mam delit medzi triedy.. kazda trieda ma mat svoju ulohu a robit len svoju cast.. 

#5 majo
Když ty entity přestanou být hloupé a naučíš je pracovat s daty, tak jim to prospěje. A toho manažera jim klidně můžeš dát jako rodiče, jeho schopnosti mohou podědit.

#6 Kit
Objekty entity vedia pracovat s datami ktore dostanu, dedia spolocneho rodica ktore im tuto funkcionalitu da.. vedia ich zmenit, extractovat atd.. ale nechcem aby vedeli odkial sa data beru, ani kto ich dodava (zdroj sa moze menit, alebo je zdrojov viac - nato mam toho managera). tiez nechcem aby ich vedeli editovat priamo v zdroji, vymazat zo zdroja atd (nato mam ine triedy)... a preto mi vznika ten problem, ze pred ich instancovanim a naslednym hydratovanim dat potrebujem ich defaultne vlastnosti ziskat.. ak pozadovane data budu kolidovat z vlastnostou entity tak sa data nesmu ani pokusat ziskat..

ak by sa jednalo o jednu sadu dat (teda iba jedna instancia entity) nebol by problem, ale napr. Select, ak ziska viac sad dat, tak musi vratit pole obsahujuce entity).. 

jedine co ma napada, instancovat si predtym entitu, s nej si vybrat co potrebujem a zahodit ju.. lenze to sa mi tiez nezda ako koser riesenie.. 

#7 majo
Podobným způsobem zpracovávám mnoho různých entit. Dokonce se některé překrývají a není s tím žádný problém. Pokud potřebuji nový pohled na data, přidám další třídu. Právě proto, že nejsou hloupé, ví přesně, co mi mají dodat, když například zavolám metodu find() nebo seek().

Gettery ani settery nepěstuji, není k tomu důvod. Vystačím si s konstruktorem.

#1 majo

#3 majo

Nemůžu se zbavit dojmu že nemáme celý obrázek toho jak,co a proč se používá, ale mozna by tomu nějaká změna prospěla. I když bych se v první fázi koukal více globálního pohledu než jen jen na použití Get/Set .

Nicméně, možná by ti ve stávající situaci mohla pomoci nějaká forma lazyloading-u.
Tj prvotní entita by se vytvořila - mělká - pouze s defaultními parametry(předpokládám že je to nějaké ID, typ atp. ktery se po nacteni dat nezmeni) a teprv při dotazu na další hodnoty, nebo na povel, by se provedlo natení z pomalého zdroje dat.
Možná by to mohlo být i tak že samotná entita bude obsahovat jen obecná defaultní data (pokud taková dokážeš určit), a zbytek který by se dotahoval by byl samostatný objekt -uvnitř entity, který by se inicializoval a dotahoval později, případně to tak trochu otočit a prvotní mělký objekt (pokud vyhovuje) jen použít k vytvoření "plného" ... .

Ale jak říkám, bylo by potřeba vědět jak to celé má fungovat a proč a jaká data chceš načítat ještě před vytvořením objektu. Také odkud pochází seznam (nevytvořených) objektů se kterými se má pracovat, kolik jich zhruba má být, atd, atd.

#9 Ovrscout
Souhlas, je to celé podivně řešené. Get/set jsou jen substitucí veřejných atributů, o zapouzdření nemůže být ani řeč.

Celý ten návrh je klasicky imperativní, s OOP nemá téměř nic společného. Statické třídy jen suplují namespace. S tímto přístupem by bylo výhodnější použít klasické strukturované programování a přineslo by to mnohem lepší benefity.

Celý ten příklad by se dal umístit do jedné stromové struktury složené ze seznamů a slovníků (asociativních polí). Že to není objektové? Úvodní příklad také ne.

nie je dost mozne to v takomto fore dobre vysvetlit, je to velmi rozsiahle (plni to podobnu ulohu ako Doctrine) a tazko to zrozumitelne vysvetlim (a tiez neviem ani moc dobre vysvetlovat svoje myslienky, sam ich chapem, ale tazko ich davam zo seba von).

kazdopadne som to cele prekopal s prihliadnutim na vase rady (oboch).. dorobil som zavislosti cez Dependency Injection a anotacie, hned je to o nieco inom :) .. cize uz je to ok, hadam.. diki ze ste ma sprdli :)