Diskuze: Návrh manažeru událostí
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Vlastník
Zobrazeno 18 zpráv z 18.
//= 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.
Přemístil bych něco z toho do SQL. Tím se to zjednoduší.
Mně vyvolávání těmi metodami pridejUdalost...() vyhovuje, krásně vidím popsané parametry co daná událost chce. Nelíbí se mi myšlenka, že budu programovat v databázi, udělal bych tam chyby. Určitě bych chtěl zachovat stávající funkčnost, jen jak třídy nejlépe rozdělit. Události mají ještě helper, takže část je již vlastně mimo manažer.
Začalo se mi líbit, že bych si tu logiku kolem dal do předka a v potomkovi implementoval jen ty metody pridej..() a vrat...(). Jen mě nenapadá jak toho předka potom pojmenovat. AbstraktniManazerUdalosti nezní moc přesvědčivě.
Tak ne, ono jich je stejně hodně, musím to rozdělit jinak.
Udělal bych asi jinak ten návrh. Mnohem lepší je mít víc malých tříd, než jednu velkou. Taky by kód měl být rozšiřitelný i bez úpravy stávajícího kódu (open-closed principle to ber samozřejmě s velkou rezervou). Udělal bych tedy nějaký interface nebo bázovou třídu, která by reprezentovala základní událost. Od toho bych pak vytvořil událost komentáře, odpovědi, označení a tu bych pak předával nějakému manažeru události, který by je dokázal, právě přes nějaké veřejné rozhraní, zpravovat. Zbavíš se velkých tříd, kdybys chtěl přidat novou událost, bude to snadné a je to i přehlednější. Hodně krát se mi tenhle přístup, mít víc malých tříd než jednu velkou, osvědčil.
Já třídy v PHP k předávání dat moc nepoužívám, předávám pole, které mi lezou i z databáze. Kdybych používal ORM, udělám to jak říkáš, ale můj způsob redukuje objem projektu, což mi vyhovuje. Ty metody z parametrů vytvoří pole, které předají metodě, která ho vloží jako řádek do databáze.
Já si zvykl psát třeba hodně přepravky a co nejvíc věcí cpát do objektů. I když zrovna nepoužívám ORM framework, data sám předám alespoň přepravce nebo vytvořím nějaké rozhraní. Pak je jasné, jak s daty manipulovat, co od toho můžu čekat, jak se má kód chovat. Asociativní pole v PHP je sice fajn věc, pěkně se s ním pracuje, ale na některé věci se prostě nehodí. Když se koukneš třeba do dokumentace Zend frameworku 2, tak tam na všechno snad používají pole a je to strašně nepřehledné.
V tomhle případě by asi nebylo pohodlné, ručně mapovat pole třeba s několika sty událostmi. Napadá mě ještě vytvořit třídy UdalostKomentar, UdalostOdpoved, UdalostOznaceni, které implementují nějaké rozhraní nebo zdědí abstraktní třídu a budou manipulovat přímo s daným typem událostí v databázi. Pak si nad tím uděláš třeba Strategy, abys měl jednu třídu, přes kterou budeš komunikovat.
Dříve to zde bylo udělané pomocí tříd a nevyhovovalo mi to. Bylo to v 12ti souborech a nyní to je v jednom, teď to rozdělím do 2, maximálně 3 a bude to zas přehledné.
Devbook má už takhle desítky tříd, měl by jich stovky, kdybych programoval striktně objektově a to nemluvím o rozhraních a dalších věcech. V PHP pole fungují díky dynamickému typování skvěle a bez problému nahradí třídy, které bych jinak u staticky typovaných jazyků musel používat. Jediná nevýhoda je, že ti IDE nenapovídá klíče, ale to je dobrá daň za tak malý objem kódu.
Na každou akci s databází mám samostatnou třídu - potomka modelu, který rozšiřuje základní model jen o potřebnou funkčnost. Tím se mi aplikace dost zrychlily. Nikde jinde v aplikaci se nesmí vyskytnout SQL a v těchto submodelech se nesmí vyskytnout HTML.
Vlastně už to nedělám jako potomka, protože bych na ten model musel použít Singleton.
A taky s polem může kdokoli manipulovat, může se ti za běhu měnit a DIC (DI kontejneru) se to taky moc nelíbí, protože je to pro něj prostě array. Vytvořením třídy (resp. rozhraní) si vytvoříš typ, který můžeš předávat a je pak jasně, co očekáváš, když máš daný typ Event, než prosté array.
Víc tříd je podle mě naopak dobře. Musíš si to rozdělit do namespace a když adresářová struktura odpovídá jmenným prostorům, obvykle nemívám ve složce víc jak 5 souborů, což projekt zpřehledňuje, i když má třeba stovky tříd.
Stejně bych musel dělat nějaké mapování toho typu na databázi, která bere zase pole Tvé tvrzení je samozřejmě naprosto správné a někde v podniku kde dělá na projektu více lidí bych tohle určitě nedělal, ale tady mi to velmi vyhovuje a dobře se v tom orientuji.
Když už se takhle bavíme, proč jsi přecházel z Aptany na PHP Storm? Stáhl jsem si jí a připadá mi dost dobrá, chybělo ti v ní něco?
Aptana je dobré IDE (plugin pro Eclipse), ale na rozdíl od PHPStormu mi tam chyběla spousta věcí, jako je třeba podpora testování, v té době ještě práce s SVN a některé další featury. Nakonec mě úplně odradila instalace pluginů do Eclipse. PHPStorm jde mnohem líp přizpůsobit, taky obsahuje spoustu pluginů, (ale tady jdou jednoduše jedním kliknutím nainstalovat), mnohem lepší a propracovanější podporu GITu, přímou podporu Composeru, pěkný deployment a spoustu dalších věcí
EDIT: nemyslel jsem to tak, že bys mapoval data z DB na objekty. Prostě by ty třídy UdalostKomentare atp. uměly pracovat s daným typem událostí v databázi. Vracely by pak normálně pole
Aptana je distribuována buď jako samostatná aplikace nebo jako plugin, stáhl jsem si tu aplikaci a vypadá to velmi dobře.
I ta samostatná aplikace je založená na Eclipse. Akorát tam nemáš tu podporu pro Javu a tak.
Tak jistě, já jen že sis stěžoval na instalaci pluginu, která takto odpadá
Já nemyslel toho pluginu Aptana studio, ale všech pluginů pro Eclipse
Nevýhodou IDE bývá právě to, že když je v adresáři víc souborů, tak se s tím moc dobře nepracuje. Třeba takový Vim touto nectností netrpí, 10k a více souborů v adresáři zpracuje s přehledem.
Zobrazeno 18 zpráv z 18.