Diskuze – Lekce 5 - UML - Class diagram

Zpět

Upozorňujeme, že diskuze pod našimi online kurzy jsou nemoderované a primárně slouží k získávání zpětné vazby pro budoucí vylepšení kurzů. Pro studenty našich rekvalifikačních kurzů nabízíme možnost přímého kontaktu s lektory a studijním referentem pro osobní konzultace a podporu v rámci jejich studia. Toto je exkluzivní služba, která zajišťuje kvalitní a cílenou pomoc v případě jakýchkoli dotazů nebo projektů.

Komentáře

Nejnovější komentáře jsou na konci poslední stránky.

Kit

Tvůrce

Kit:27.2.2013 17:15

Chytré to je, ale já to nevymyslel. Je to součástí TDD. Pokud se to dělá důsledně, v aplikaci se to podobnými konstrukcemi jen hemží.

Objekt databáze obvykle předám konstruktoru modelu a objekt modelu pak předám controlleru nebo vieweru, který vyrobím ve factory. Z programu se tak stane skládačka, ve které se dá otestovat každá komponenta zvlášť.

Odpovědět

Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.

Juraj Mlich

Tvůrce

Juraj Mlich:1.7.2013 10:31

Ako zapíšem preťaženú metodu?

Odpovědět

Milan Gallas

Tvůrce

Milan Gallas:3.12.2013 19:05

Napsal jsi statiku nepoužívej, ale jak chceš zajistit například jedinečnou instanci nějaké třídy. Při práci v týmu budeš muset nějak zajistit, aby si každý programátor v týmu nemohl vytvořit instancí třídy (která zajišťuje připojení k databázi, nebo nějaké ladící nástroje)? Jednu jedinečnou instanci bez návrhového vzoru Singleton(který využívá principy statiky) neuděláš a pokud znáš způsob jak v tomhle případě statiku obejít, tak mi ho prosím zděl

Odpovědět

Drahomír Hanák

Tvůrce

Drahomír Hanák:3.12.2013 20:10

O to, aby byla instance jedinečná, se mi stará DI kontejner

Odpovědět

Milan Gallas

Tvůrce

Milan Gallas:3.12.2013 23:12

i to má svůj problém.
pro konkrétní případ si dovolím půjčit tvojí továrnu, kterou máš popsanou v článku http://www.itnetwork.cz/…avrhovy-vzor

Ber v úvahu, že tvoji kolegové ve firmě nebudou vědět, že pro získání objektu můžou zvolit metodu getConnection(), ale vytvoří si novou instanci třídy Container a zavolají znovu metodu createConnection(); Pokud již budeš mít takto vytvořený objekt a některý z tvých kolegů si vytvoří další instanci tak Vytvořené objekty nebudou stejné a bude docházet k plýtvání pamětí.

Kdybych použil Singleton tak použiji privátní konstruktor a přinutím je používat metody getConnection, ale ty je nijak nepřinutíš a oni si můžou vytvořit tolit instancí, kolik budou chtít.

Odpovědět

Milan Gallas

Tvůrce

Milan Gallas:3.12.2013 23:21

a navíc třídu Container si může kdokoli naklonovat a to tvoje třída také vůbec neřeší:

$container = new Container('Localhost', 'test', 'aaabbb', 'myTable');
$db = $container->createConnection();
$db2 = clone $db;

Pokud mi tyhle 2 věci vyvrátíš, tak uznám svou chybu a uznám že jsem se spletl, ale zatím si myslím, že Ten kontejner má své nedostatky a že nedokáže zajistit na 100ˇ%, aby existovala pouze **1 **instance dané třídy.

Odpovědět

Drahomír Hanák

Tvůrce

Drahomír Hanák:3.12.2013 23:25

Já mám v práci chytré kolegy, kteří znají ten návrhový vzor a ještě chytřejší DIC, který nikomu nedovolí tohle udělat (dokonce umí sám ty závislosti třídám předávat) Paradoxně hlavní problém singletonu je nepřehlednost. Třída si někde magicky z globálního prostoru vezme instanci. Přitom má signaturu třeba class UserDao(); Kde z toho poznám, že potřebuje databázi? A když si podle názvu odvodím, že asi nějakou databázi potřebuje, odkud si ji vezme? A jak ji v testech budu mockovat? Z praxe vím, že Singleton ve větších aplikacích nenahradí DI. Dokonce jsem se setkal s případem, kdy firma měla v jedné aplikaci tohle řešení singletony. Jak na aplikaci dělalo stále víc lidí, muselo se to prostě přepsat.

Nechci to nikomu nutit, mluvím na základě svých zkušeností z pár firem a vlastních projektů. Určitě jsou tu zkušenější uživatelé, kteří ti poradí mnohem lépe.

Mimochodem, tomu zneužití co píšeš, se dá dost jednoduše zamezit.

Editováno

Odpovědět

Milan Gallas

Tvůrce

Milan Gallas:3.12.2013 23:31

a jak si to teda v tom svém DIC vyřešil, Aby výše zmíněné věci nebyly možné a DIC to nikomu nedovolilo?
Mě jde o konkrétní postup zamezení těchto 2 "ohavností", které ti můžou tvoji kolegové způsobit.

Odpovědět

Drahomír Hanák

Tvůrce

Drahomír Hanák:3.12.2013 23:56

K instanci DIC vůbec nemají přístup nebo jen velmi omezený.
V DIC si definuji službu buďto jako service (vytváření instancí je plně pod kontrolou kontejneru tj. createConnection je privátní) nebo jako factory (očekávám, že bude instancí víc, tady předávám tovární funkci) Klonování si např. v PHP ošetříš pomocí vlastní definice __clone().

O tom, že by uživatel vytvořil kontejner nemá cenu diskutovat. Třídy uvnitř systému nikdy nebudou vědět, že nějaký kontejner existuje. Kdyby ho někdo přece jen vytvořil ručně sám (což je velice nepravděpodobné), musel by do něj definovat všechny služby a továrny z celého systému znovu, aby mu to fungovalo.

Ty mi zase řekni, jak mám mockovat singleton v testech? Co když budu chtít přepínat mezi uložišti (databáze/cache)? Co když tam přidám v průběhu vývoje další možnosti? Abys udělal tohle, musel bych nejspíš narušit základní návrhové principy (jako třeba single responsibility, open-closed princip dokonce princip převrácaného předávání závislostí je základním principem). Nebo jak tedy jasně zjistit závislosti třídy? To, že je globální taky není moc ok. Nevýhody singletonu tedy alespoň pro mě jasně převyšují nevýhody DI (můžeme se dál bavit o tom, že si někdo ručně vytvoří tu službu nebo použije reflexi, ale nemá to cenu, protože to se v praxi nestane)

Odpovědět

Drahomír Hanák

Tvůrce

Drahomír Hanák:4.12.2013 0:08

Abych to ještě uvedl na pravou míru. To, o čem tu diskutujeme, není Dependency Injection, ale Dependency Injection Container (DIC). DI je v zásadě i toto: new UserDao(new Database('localhost')) i když takhle zapsané to není v praxi použitelné.

Ještě bych chtěl možná zmínit, že DI a singleton se navzájem nevylučují.

Editováno

Odpovědět

Nejnovější komentáře jsou na konci poslední stránky.

Naučíme tě pracovat na home-office.

Zjistit více...

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 10 zpráv z 32.

Nejčastěji vyhledáváné

Diskuze – Lekce 5 - UML - Class diagram