Vlákno názorů ke článku Dependency Injection ještě jednou :-) od RS - Ok je vikend mam vic casu takze jsem...
-
Ok je vikend mam vic casu takze jsem to procetl jeste jednou a poskytnu ucelenou odpoved:
Zde jsou důvody:
--- Přináší to do aplikace další složitost, která však není k ničemu reálně užitečná.
Slozitost to naopak ubira protoze komponenta NENI zavysla na zadnem externim kontejneru jako jednotce je ji to JEDNO protoze vsechno dostava ZVENKU. Muzu vymenit 1 DI mechnizmus za druhy a komponente je to jedno. Pripadne ji muzu predat zavyslosti rucne opet je to jedno.. co JE komplikovane je samotny DI kontejner (napsat ho rozumne efektivne neni prace pro kazdeho, proto ho kazdy nepise a pouzije uz hotovy, overeny, otestovany), me jako uzivatele to ale nezajima..--- Zatěžuje to vývojáře a odvádí jej to od řešení podstaty věci. Prostě další věc na kterou musí myslet aniž by to přineslo reálný užitek a potřebnou efektivitu.
Opet neni pravda jako vyvojarna to prave diky DI kontejnerum vubec myslet nemusim protste pridam parametr do konstruktoru a DI kontejner se o vse postara sam, ja pracuju ze svou jednotkou a o nic se nestaram, kdyz zavyslost dale nepotrebuju proste ji uberu jak jsem psal driv povetsinou musim udelat zmenu prave na 2 mistech v samotne sluzbe a pak v jejim unit-testu.
--- Pokud používáte framework s nějakými konfigurovatelnými kontejnery a ještě ke všemu v nějakém nestandardním datovém formátu, tak vám to objektivně sníží technickou efektivitu aplikace.
Toto proste neni pravda.. evidentne s tim nemate zkusenost
-
Přidám: Krásná demonstrace loose couplingu - Když vytvořím nějakou vymazlenou logiku v nějakém prostředí respektující DI, tak ji mohu s minimálními úpravami vzít a přestěhovat klidně do php-jet. Když tuto logiku napíšu stylem, který je pro php-jet doporučován, tak když tu logiku budu chtít přesunout jinam tak mám smůlu. Strávím spustu a spoustu času na vyškubání těch vnitřních závislostí.
