Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Jana J. 06. 05. 2014, 11:42:12
-
Zdravím, potřebuji vytvořit pomocnou třídu, která bude parsovat url, zjišťovat přihlášení uživatele, kontrolovat error404, čísla stránky atd.. Poradí někdo vhodný název? Díky
-
prasacky_navrzena_trida
-
MasloStroj
-
ParseUrl_Login_Error404_FindPageNumber_Helper_Dafuq
::) ;D :o
P.S. Pokud se vám pomoc nezdá konstruktivní, bude to patrně tím, že podle popisu funkcí je název toho příšerného bastlu naprosto posledním problémem, který by vás měl trápit.
-
Už to tady v podstatě zaznělo, ale jedna ze zásad OOP je, že pokud máš něco problém pojmenovat, tak to je špatně navržený.
Každá třída by měla dělat pokudmožno pouze jednu věc a měla bys o ní být schopna říci, co dělá (jaká je její zodpovědnost). Pokud to má být nějaká třída starající se o celý běh webové aplikace, zkus z ní jednotlivé činnosti vyčlenit do samostatných tříd...
-
Už to tady v podstatě zaznělo, ale jedna ze zásad OOP je, že pokud máš něco problém pojmenovat, tak to je špatně navržený.
Každá třída by měla dělat pokudmožno pouze jednu věc a měla bys o ní být schopna říci, co dělá (jaká je její zodpovědnost). Pokud to má být nějaká třída starající se o celý běh webové aplikace, zkus z ní jednotlivé činnosti vyčlenit do samostatných tříd...
Děkuji, právě mi přišlo špatné, vytvářet samostatné třídy ve které bude jedna metoda...
-
Děkuji, právě mi přišlo špatné, vytvářet samostatné třídy ve které bude jedna metoda...
Takové třídy jsou v OOP běžné.
-
Zdravím, potřebuji vytvořit pomocnou třídu, která bude parsovat url, zjišťovat přihlášení uživatele, kontrolovat error404, čísla stránky atd.. Poradí někdo vhodný název? Díky
Parsování URL - něco s tím výsledkem budeš asi dělat. Konstruktoru můžeš předat URL, výsledek se uloží v atributech. Pak zavoláš tovární metodu, která ti vyrobí z toho URL potřebnou třídu na zpracování.
Přihlášení uživatele - další samostatná třída, která není tak triviální, jak na první pohled vypadá. Vzniklý objekt poskytuje autorizační informace - na to jedna metoda obvykle nestačí.
Kontrola error404 bude zřejmě součástí parsování URL, při pokusu o výrobu nevyrobitelného objektu.
Číslování stránek - to bude asi součástí vieweru. O to se může postarat výstupní šablona.
-
Chtěla jsem to cpát do jedé class z důvodu, abych taky všude netahala spoustu instanci. Podívám se ještě na nějaké názorné příklady. Moc děkuji za pomoc.
-
Tohle vypadá jako klasický příklad na použití návrhového vzoru (hezky česky) Fasáda.:) http://en.wikipedia.org/wiki/Facade_pattern
-
ked som este robil v php, tak tiez som mal jednu triedu, kde bolo vsetko co sa tykalo db, parsovanie url, a vlastne vsetky funkcie.
Fungovalo to bez problemov a dost svizne (bol to intenzivne navstevovany eshop). triedu som nazval podla firmy, pre ktoru to bolo.
-
navrh triedy, ktora robi uplne vsetko je zly navrh a v PHP je caste, ze jeden obrovsky projekt sa sklada z viacerych stavebnych kamenov ako skladacka (parser_URL, SQL,...)
a je to aj ovela lahsie udrzatelne...
a trieda by mala robit iba jednu ciastkovu cinnost z celej aplikacie (nie parsovatURL, prihlasovat uzivatelov, pracovat s nakupnym kosikom,...)
-
Takové třídě se říká router. Ale je důležité podotknout, že ona nic z toho ve skutečnosti nedělá, pouze to přepošle instanci jiné třídy, kterou umí najít, a výsledky složí do nějaké stavové proměnné.
-
Pro jednoradkove funkce/metody muzes klidne vytvorit utilitni tridu (vse static). A pak to nazvat treba Utils (v nejakem namespace).
-
Tohle vypadá jako klasický příklad na použití návrhového vzoru (hezky česky) Fasáda.:) http://en.wikipedia.org/wiki/Facade_pattern
Ano, to je poměrně hezké a čisté řešení.
Existují shluky malých a často nesouvisejících metod, které se dají takto obalit, ale nevím, jestli to standardní zprasovatel (programátor v PHP) zvládne ;D
-
este mi napada otazka: naco je mat vobec v takomto php pripade triedu, ked je to len obal na nahodne zhromazdene funkcie? ;-)
-
Fasáda není obal na nahodne shromáždené fce. Má místo toho ulehčit práci s objekty. Dejme tomu, že pro ověření, zda uživatel může na stránku potřebuju vytáhnout uživatele podle session, převzít název stránky z url a obe informace ověřit proti DB. Tzn mám dejme tomu 3 třídy, které umožňují provést jednotlivé požadované kroky (uživatel, urlparametry, ověření) a budu podobnou činnost dělat na více stránkách opakovaně. Proto abstrahuji posloupnost kroků do metody fasády a pouze parametrizuji vstup a kontroluji výstup. Tzn skrývá mi to složitou logiku.
-
Ano, má to význam.
Řekněme tomu třeba buffer.
Než abys tady nechal nějaké svinstvo různě povalovat stylem támhle kousek bordelu, tady špínu, támhle papírek, šoupneš to do jedné krabičky a máš uklizeno. Pokud se ti v té krabičce nastřádá deset podobných kravinek, zjistíš to snáz, než abys (což nikdo PAK STEJNĚ nedělá) prohledával kód a koukal se, jestli se někde nedá něco spojit.
Já třeba nemám rád samostatné třídy obsahující tři řádky kódu, který něco provádí! Když už, tak je obalit!
Další výhoda "Maslostroje" je v tom, že když se rozhodneš nějaký bordel sloučit, hledáš odkazy jen na "Maslostroj".
Pokud nejsi sprasovatel (čti programátor v PHP) definuješ, že bordel může být jen v _MasloStroj a nikde jinde, takže buď to píšeš čistě, nebo přidáváš do _MasloStroje. S trochou píle se dá _MasloStroj uklidit, takže výsledkem bude sice chrchel na první pohled nesouvisejících metod, ale protože _MasloStroj je jen obálka (fasáda) pak i v tom svém bufferu máš pořádek.
Jsou programátoři, kteří programují řekněme živelně a ti, kteří si vše dobře naplánují.
Pokud patříte k těm živelným, v první fázi vše naboucháte do _MasloStroje, ale už předem počítáte s tím, že se to bude muset přepsat.
Ten kdo nemyslí deset tahů dopředu si s tím může i vystačit. Jak třídy do _MasloStroje (ten název se mi moc líbí!) přibývají, poškrábete se na kebuli a začnete v tom dělat pořádek, takže se obsah bufferu vyprazdňuje a zůstane tam jen skutečný herberk.
Někomu to vyhovuje, když napíšete většinu funkcí, kouknete se na to a celé to zjednodušíte.
No někdo si zase raději napíše specifikaci a ti nejšťastnější z nás to píšou z voleje dočista.
-
Fasáda není obal na nahodne shromáždené fce. Má místo toho ulehčit práci s objekty. Dejme tomu, že pro ověření, zda uživatel může na stránku potřebuju vytáhnout uživatele podle session, převzít název stránky z url a obe informace ověřit proti DB. Tzn mám dejme tomu 3 třídy, které umožňují provést jednotlivé požadované kroky (uživatel, urlparametry, ověření) a budu podobnou činnost dělat na více stránkách opakovaně. Proto abstrahuji posloupnost kroků do metody fasády a pouze parametrizuji vstup a kontroluji výstup. Tzn skrývá mi to složitou logiku.
Tak to zřejmě bylo původně myšleno, to nepopírám :P
V každém případě to funguje i na udržení pořádku, což v tomhle případě řešíme ne?
Protože pokud použiješ Fasádu jako obal na bordel, máš bordel v nejhorším na jednom místě, což je lepší, než ho mít všude v kódu.
-
Dřív jsem malé a nicnedělající třídy flákal jako Baťa cvičky, až jsem zjistil, že to je kontraproduktivní, protože s jejich narůstajícím počtem vzniká problém se v nich vyznat a co hůř, udělat je znovupoužitelné, tedy když programuju "divoce". Použití malých samostatných tří vedlo jen k tomu, že jsem nevytvářel znovupoužitelný kód, protože poprvé jsem tu třídu "tak teda udělal", podruhé to "nějak ohnul", potřetí přepsal a počtrvé k tomu ve fofru přidělal nějaký cancour, který dělal kdo ví co. Od té doby si třídy, které nejsou na první pohled nikam snadno zařaditelné, cpu do tohoto bufferu a když se tam toho objeví víc, a já už vím, co to všechno bude muset dělat, navrhnu dobrou třídu, navrhnu jí správně a z bufferu to vyndám. Díky tomu se mi v kódu neválí chrchle zapomenutého kódu.
App, můžete se mě pokusit přesvědčit, že je lepší mít deset "skoronicnedělajících" tříd než jeden bordel buffer.
Rád bych slyšel nějaké opravdu pádné argumenty.
A zase, netvrdím, že to bude vyhovovat 9ti z 10ti programátorů, tvrdím, že to vyhovuje mě, schovávat svinstvo za fasádu, pak si tam uklidit a kód je v pohodě.
-
Facade je opravdu dobrý vzor, pokud je potřeba něco rychle naprasit. Wrapper se mi pak stará o konzistenci a hacky (rekurze). Většinu lidí zajímají akorát dvě věci: 1) Za kolik, 2) Za jak dlouho. U jednorázovek to stejně skončí u toho _MasloStroje, pokud se na tom dělá dále, tak se uklízí.