ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 126
Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 83
Abonament PDF

Dependency Injection - Interviu cu Mark Seemann

Ovidiu Mățan
Fondator @ Today Software Magazine



INTERVIU

tăm de vorbă cu Mark Seemann, co-autorul cărții Dependency Injection Principles, Practices, and Patterns. Mark a fost speaker la ediția de anul trecut a IT Days unde prezentarea sa, Human Code, a câștigat votul publicului. Va fi prezent din nou luna aceasta la Cluj unde va vorbi despre Asynchrnous Injection la conferința The Developers 2019

Vă începeți cartea cu o analogie interesantă între o priză, un sos Béarnaise și Dependency Injection. Care este legătura dintre acestea?

Mark Seemann: Ambele sunt analogii. Există două moduri de a privi Dependency Injection.

Analogia cu priza scoate în evidență ideea de polimorfism și tiparele diverse de design ce rezultă din polimorfism. Priviți priza ca o interfață. Orice ștecher care se potrivește în priză va permite curentului electric să treacă. Prizele diferite (e.g. US vs. Europa) corespund unor interfețe diferite. Adaptorii există, iar tiparul Adapter Design vă permite să faceți ca un obiect să arate ca un altul.

Analogia cu sosul Bèarnaise scoate în evidență ideea că este greu de învățat, dar după ce ai învățat, devine un lucru ușor, de bază chiar. De fapt, sosul Hollandaise ar fi o analogie mai bună, deoarece acesta este sosul de bază de la care obținem sosul Bèarnaise și alte sosuri. Am ales sosul Bèarnaise pentru că este mai cunoscut. Nu mă așteptam ca publicul să știe ce este sosul Hollandaise.

Este Dependency Injection același lucru ca Inversion of Control?

Mark Seemann: Cred că nu este vorba de același lucru și cred că am învățat acest lucru din lucrările lui Martin Fowler. Dependency Injection este o formă de Inversion of Control, dar Inversion of Control este un concept mult mai larg care include și utilizarea de frameworkuri de aplicație.

Totuși, distincția poate fi o luptă pierdută. Pentru mulți programatori, distincția nu există, folosind termenii ca sinonime. Prefer termenul Dependency Injection în toate cazurile în care nu mă refer explicit la un concept mai larg.

Ce tipare de design recomandați să fie utilizate în Dependency Injection? Există și anti-tipare?

Mark Seemann: Cele mai utile tipare sunt Composite, Null Object, Decorator, Chain of Responsibility, Visitor. Dependency Injection este doar un sinonim pentru tiparul Strategy, dar Dependency Injection include tipare pentru modul în care Strategy colaborează cu consumatorii. Cel mai util tipar este Constructor Injection.

Un alt tipar Dependency Injection este Composition Root. Compuneți întregul grafic de obiecte pentru aplicație în punctul de intrare în aplicație.

În ceea ce privește anti-tiparele, cel mai frecvent este Service Locator. Din păcate, programatorii încep de obicei cu acest lucru, iar mulți presupun că acesta este modul recomandat de utilizare a Dependency Injection.

Ambient Context este de evitat.

Utilizarea unui DI Container nu este un anti-tipar, dar mulți cred că Dependency Injection necesită DI Container, iar această gândire duce ușor la anti-tiparul Service Locator. Eu recomand ca, dacă nu știți ce faceți, să nu folosiți DI Container.

La ce trebuie să fie atenți programatorii când verifică o implementare DI?

Mark Seemann: Primul lucru pe care îl verific este dacă Service Locator este prezent. Verific și dacă DI Container este inclus în cod.

Este util să identificăm care este graficul de dependințe din cod. Care părți din cod depind de alte părți? Programatorii își împart codul în librării - deși de multe ori le numesc "straturi" (layers). Aceste librării vor fi conectate unele de altele într-un grafic. Este bine de știut cum arată acest grafic. Poate va trebui să îl desenați pe o hârtie. Cu toate că "analiza dependințelor din grafic" ('dependency graph analysis') poate suna academic și abstract, acest grafic e simplu și se poate realiza în câteva minute.

Am întâlnit multe exemple de cod unde dependințele au fost prost înțelese și implementate. Un grafic de dependințe scoate problemele la lumină.

La ce să ne așteptăm de la prezentarea dumneavoastră de la conferința The Developers 2019?

Să se aștepte să învețe ceva nou.

VIDEO: NUMĂRULUI 126

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Colors in projects