Diskuze: Návrh manažeru událostí

PHP PHP Návrh manažeru událostí American English version English version

Avatar
David Čápka
Tým ITnetwork
Avatar
David Čápka:

Velmi mi narostla třída, která spravuje události na devbooku. Mám v ní metody jako jsou:

  • pridatUdalostKo­mentare(...)
  • pridatUdalostKo­mentarePodCla­nek(...)
  • pridatUdalostOd­povedi(...)
  • pridatUdalostOz­naceni(...)
  • PridatUdalostHod­noceni(...)

...

A tak dále. Metody mají průměrně asi 7 řádků, připraví událost na základě parametrů a tu předají privátní metodě, která ji vloží do databáze.

Dále jsou zde opačné metody, které tyto události vrátí:

  • vratUdalostiKo­mentare(...)
  • vratUdalostiKo­mentarePodCla­nek(...)

...

A tak dále. Když se přidá ještě několik podpůrných privátních metod a PHP dokumentace, 1000 řádků je na světě. Jak bych to měl rozdělit, abych neměl tak velkou třídu?

Napadlo mě dát část do předka a potom to oddědit a přidat další. Třeba takhle:

class ManazerUdalosti extends PridavacUdalosti

Také mě samozřejmě napadlo úplně oddělit přidávání a čtení událostí do 2 tříd.

Líbí se mi, že manažer má v kompetenci vše co se týče událostí, ale je toho zkrátka už moc. Oddědit, rozdělit nebo případně nějaké další řešení?

Odpovědět 5.4.2013 15:16
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
Kit
Redaktor
Avatar
Odpovídá na David Čápka
Kit:

Přemístil bych něco z toho do SQL. Tím se to zjednoduší.

Nahoru Odpovědět 5.4.2013 15:22
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Avatar
David Čápka
Tým ITnetwork
Avatar
Odpovídá na Kit
David Čápka:

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. AbstraktniMana­zerUdalosti nezní moc přesvědčivě.

Nahoru Odpovědět 5.4.2013 15:33
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
David Čápka
Tým ITnetwork
Avatar
David Čápka:

Tak ne, ono jich je stejně hodně, musím to rozdělit jinak.

Nahoru Odpovědět 5.4.2013 15:35
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na David Čápka
Drahomír Hanák:

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.

Editováno 5.4.2013 15:52
 
Nahoru Odpovědět  +1 5.4.2013 15:50
Avatar
David Čápka
Tým ITnetwork
Avatar
Odpovídá na Drahomír Hanák
David Čápka:

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.

Nahoru Odpovědět 5.4.2013 16:02
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na David Čápka
Drahomír Hanák:

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.

 
Nahoru Odpovědět 5.4.2013 20:25
Avatar
David Čápka
Tým ITnetwork
Avatar
Odpovídá na Drahomír Hanák
David Čápka:

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.

Nahoru Odpovědět 6.4.2013 8:37
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
Kit
Redaktor
Avatar
Odpovídá na David Čápka
Kit:

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.

Nahoru Odpovědět 6.4.2013 9:53
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Avatar
Kit
Redaktor
Avatar
Odpovídá na Kit
Kit:

Vlastně už to nedělám jako potomka, protože bych na ten model musel použít Singleton.

Nahoru Odpovědět 6.4.2013 10:16
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na David Čápka
Drahomír Hanák:

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.

 
Nahoru Odpovědět 6.4.2013 11:14
Avatar
David Čápka
Tým ITnetwork
Avatar
Odpovídá na Drahomír Hanák
David Čápka:

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?

Nahoru Odpovědět 6.4.2013 14:36
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na David Čápka
Drahomír Hanák:

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 ;)

Editováno 6.4.2013 14:56
 
Nahoru Odpovědět 6.4.2013 14:54
Avatar
David Čápka
Tým ITnetwork
Avatar
Odpovídá na Drahomír Hanák
David Čápka:

Aptana je distribuována buď jako samostatná aplikace nebo jako plugin, stáhl jsem si tu aplikaci a vypadá to velmi dobře.

Nahoru Odpovědět 6.4.2013 15:05
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na David Čápka
Drahomír Hanák:

I ta samostatná aplikace je založená na Eclipse. Akorát tam nemáš tu podporu pro Javu a tak.

 
Nahoru Odpovědět 6.4.2013 15:09
Avatar
David Čápka
Tým ITnetwork
Avatar
Odpovídá na Drahomír Hanák
David Čápka:

Tak jistě, já jen že sis stěžoval na instalaci pluginu, která takto odpadá :P

Nahoru Odpovědět 6.4.2013 15:13
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
Drahomír Hanák
Tým ITnetwork
Avatar
Odpovídá na David Čápka
Drahomír Hanák:

Já nemyslel toho pluginu Aptana studio, ale všech pluginů pro Eclipse :)

 
Nahoru Odpovědět 6.4.2013 15:36
Avatar
Kit
Redaktor
Avatar
Odpovídá na Drahomír Hanák
Kit:

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.

Nahoru Odpovědět 6.4.2013 15:49
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 18 zpráv z 18.