Diskusia – 5. diel - UML - Class diagram

Späť

Upozorňujeme, že diskusie pod našimi online kurzami sú nemoderované a primárne slúžia na získavanie spätnej väzby pre budúce vylepšenie kurzov. Pre študentov našich rekvalifikačných kurzov ponúkame možnosť priameho kontaktu s lektormi a študijným referentom pre osobné konzultácie a podporu v rámci ich štúdia. Toto je exkluzívna služba, ktorá zaisťuje kvalitnú a cielenú pomoc v prípade akýchkoľvek otázok alebo projektov.

Komentáre

Posledné komentáre sú na spodnej časti poslednej 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ášť.

Odpovedať

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?

Odpovedať

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

Odpovedať

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

Odpovedať

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.

Odpovedať

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.

Odpovedať

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.

Editované

Odpovedať

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.

Odpovedať

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)

Odpovedať

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í.

Editované

Odpovedať

Posledné komentáre sú na spodnej časti poslednej stránky.

Robíme čo je v našich silách, aby bola tunajšia diskusia čo najkvalitnejšia. Preto do nej tiež môžu prispievať len registrovaní členovia. Pre zapojenie sa do diskusie sa zaloguj. Ak ešte nemáš účet, zaregistruj sa, je to zadarmo.

Zobrazené 10 správy z 32.

Najčastejšie vyhľadávané

Diskusia – 5. diel - UML - Class diagram