ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 142
Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 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 77
Abonament PDF

Design patterns și dependency injection - Interviu Mark Seeman

Ovidiu Mățan
Fondator @ Today Software Magazine



INTERVIU

"Dependency Injection" este un tipar de design folosit de toate paradigmele moderne. În 2012 ați publicat o carte pe această temă. Ce ne puteți spune despre acest subiect și de ce ar trebui să citească programatorii cartea?

Mark Seeman: Mi se pare că există un sentiment ce se cristalizează în mințile vizionarilor de vârsta mea sau mai bătrâni, anume că problema cea mai mare a dezvoltării actuale de software este interdependența între programe (coupling). Este un factor ce distruge proiectele software.

Codul crește în complexitate până când se prăbușește sub propria greutate. În cazul codurilor care au un grad de interdependență foarte mare, fiecare bucată de cod este legată de toate celelalte elemente. Repari un bug aici, dar introduci alte două în altă parte. Adaugă o funcționalitate simplă, dar vei edita zeci de fișiere.

Pentru a menține codul sustenabil, va trebui să controlați interdependența îndeaproape. "Dependency Injection" reprezintă o astfel de încercare. Utilizând polimorfismul bazat pe obiecte, inserați (injectați) dependințe în obiecte. Unii mai numesc procesul "inversarea controlului", deși acesta este un concept mai general.

Puteți citi despre aceste idei peste tot pe internet, aceasta fiind situația și în 2010. Totuși, toate lucrările care încearcau să explice "Dependency Injection" aveau abordări diferite pentru a explica acest concept, folosind vocabular vag sau imprecis. Pe scurt, în ciuda faptului că toată informația era disponibilă, a fost greu să găsim o introducere bună în subiect. Din acest motiv, am decis să scriu o carte cu un limbaj consistent, bine definit.

Cartea a fost bine primită de public, deci cred că aceasta îi va ajuta pe oameni să reducă interdepedența și să mențină codul fiabil cu mai mare ușurință. A doua ediție a cărții se va publica zilele acestea. Steven van Deursen a depus efort în actualizarea textului, iar feedbackul pe care l-am primit referitor la a doua ediție arată că oamenilor le-a plăcut ce au citit. Cred că Steven a realizat un lucru deosebit.

Prezentarea dumneavoastră de la IT Days va fi despre Codul Uman (Human Code). Vă bazați pe o teorie interesantă, care ia în calcul codul scris sau citit de programatori zi de zi. Spuneți-ne mai multe despre acest subiect.

Mark Seeman: Cred că are legătură cu interdependența între programe. De ce este această interdependență atât de greu de gestionat?

Ce se întâmplă când dezvoltăm software? Pe lângă introducerea datelor de la tastatură, ne petrecem timpul citind codul existent pentru a ne da seama cum putem să îl schimbăm sau să îl îmbunătățim. Petrecem mult timp citind codul existent.

Ce se întâmplă când citim cod? Din câte îmi dau seama, toți programatorii își creează 'un simulator mental' în creier și cumva încearcă să 'ruleze' codul în acel simulator mental. Acest lucru presupune monitorizarea stării programului, a variabilelor, a flagurilor (atenționărilor).

Psihologia experimentală indică faptul că memoria noastră de scurtă durată poate monitoriza doar un număr limitat de elemente. Un studiu celebru menționează cifra 7 (plus/minus 2).

Interdependența între programe ne distruge abilitatea de a 'rula' codul complex cu încredere în creierul nostru, deoarece creierul uman pur și simplu nu poate monitoriza zeci sau sute de variabile.

Aceasta este problema cu dezvoltarea de software modern. Nu este vorba despre cum se poate echilibra un arbore binar sau despre cum să scrii un algoritm eficient de sortare. Aceste probleme au fost rezolvate acum câteva decenii. Problema care persistă este să ne dăm seama cum să scriem cod în funcție de limitările creierului uman.

Ce părere aveți despre tiparele de design din ziua de azi, când cele mai multe dintre ele sunt deja încorporate în limbajele de programare moderne?

Mark Seeman: Nu sunt de acord cu acest lucru, dar depinde de limbaj, presupun. Care sunt limbajele care au, de exemplu, tiparul de design Visitor inclus? Nu C# sau Java, dar surprinzător, limbajele derivate ML precum F# și Haskell au incluse tiparul acesta. Totuși, în aceste limbaje, funcționalitatea nu se numește Visitor, ci 'sum types' sau 'discriminated unions'. Se poate însă demonstra că "sum types" sunt echivalentul tiparului de design Visitor.

O critică frecventă a tiparelor de design este că oferă soluții la deficiențele unor limbaje particulare, și, cu toate că sunt de acord cu noțiunea, nu cred că sunt motive să respingem ideea de tipare. Dacă ne întoarcem la cartea originală Gang-of-Four, un tipar de design este o soluție comună la o problemă curentă. Aceste probleme apar când un limbaj nu oferă o soluție explicită. Din nou, Visitor este un exemplu bun: ocazional, trebuie să puteți modela datele din cadrul unui set finit de cazuri eterogene, în distribuție complementară, iar limbaje precum C# sau Java oferă funcționalități explicite pentru a rezolva un anume tip de probleme. Aderați la tiparul de design Visitor.

Când un limbaj oferă suport pentru o anumită problemă, nu e nevoie de un tipar de design pentru acest lucru. Este doar o funcționalitate specifică unui limbaj, așa cum este cazul sumelor Haskell.

De când s-a publicat cartea Gang of Four, unele dintre tiparele din acea carte au devenit funcționalități specifice pentru un anumit limbaj. De exemplu, C# a dezvoltat sintaxa 'foreach', care este o trăsătură de limbaj ce implementează tiparul de design Iterator. Astfel, rar veți auzi programatorii C# vorbind despre tiparul de design Iterator, deoarece se află deja acolo în limbaj.

În general, cele mai multe tipare de design nu sunt dezvoltate în limbajele moderne. Nu sunt la curent cu limbaje ce au funcționalități explicite ce implementează Adapter, Facade, Singleton, Bridge, și așa mai departe, iar limbaje precum C# sau Java nu au funcționalități explicite pentru Composite, Chain of Responsibility, etc. . Mai mult, trebuie luat în considerare că există mai multe tipare de design decât cele descrise în cartea Gang-of-Four. Cele mai populare sunt tiparul Null Object și tiparul Value Object.

Eu cred că vom folosi tipare de design multe decenii de acum încolo, dar accentul se va modifica. Nu doar că noile limbaje absorb tiparele de design vechi, dar noile probleme vor da naștere la noi tipare. Tiparele din cartea Gang-of-Four sunt intim legate de software pentru desktop. Acestea oferă soluții la problemele software cu mai mulți clienți, precum maniera în care să se implementeze sisteme de tip fereastră, manual context-sensitive, funcționalitate "undo" și altele. Multe din aceste probleme sunt acum rezolvate fie de sistemele de operare, fie au devenit complet irelevante într-un mediu de tip "web pe primul loc", sau "smartphone pe primul loc". Totuși, noile tipare apar, deoarece acele contexte vin cu alte tipuri de probleme.

Cum vedeți evoluția Agile? La ce ar trebui să ne așteptăm în ceea ce privește agilitatea în cadrul echipelor?

Mark Seeman: Este amuzant, oamenii mă privesc ca expert în dezvoltarea software Agile și mă întreb de ce. Rar am vorbit despre acest subiect și nici nu am scris multe despre asta.

Am petrecut un an într-o organizație ce făcea Scrum în mod formal, dar dincolo de asta, am fost în organizații ce aderau la metodologia "fă lucrurile să funcționeze" ('get shit done'). Există câteva trucuri pentru a obține acest obiectiv. Dezvoltarea bazată pe teste sau cel puțin testele comprehensive efectuate, ajută foarte mult în acest sens. Livrarea continuă este crucială.

Nu trebuie să urmați o metodologie formală pentru a realiza ceva, deși am făcut rareori acest lucru. Însă ceea ce fac este să ofer răspuns la feedback. Dacă un proces ajută, repetați-l. Dacă un proces nu ajută, nu îl mai practicați.

Totuși, cred că succesul meu în livrarea de software funcțional a fost legat de munca în echipe mici. În puținele ocazii, când am făcut parte din echipe mari, proiectul a eșuat. Proiectele mici au o șansă mai mare de a reuși, motiv pentru care livrarea continuă este importantă. Nu este nimic nou. Fred Brooks descrie acest fenomen în cartea 'The Mythical Man-Month' din 1975.

Agile și-a pierdut de atunci pentru mine fascinația. În aceste zile, termenul 'Agile' a fost cooptat de manageri și este puțin legat de ideile sale originare din Manifestul Agile. Cred că această tendință va continua, dar 'Agile' implică deja un proces formal - exact opusul a ceea ce a însemnat la început.

Noile generații de programatori vor redescoperi probabil principiile Agile și vor găsi un nou termen pentru acestea. Ideile inițiale din spatele dezvoltării de software Lean Agile sunt suficient de utile, iar ideile noi vor apărea și ele.

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects

INTERVIURI VIDEO