'Y'

Principiul YAGNI

Oare principiile OCP (The Open Closed Principle) si DIP (The dependency Inversion Principle) din cadrul SOLID incalca principiul YAGNI? Haideti sa analizam aceasta intrebare in detaliu.

Nov 1, 2016 1821
Oare principiile OCP (The Open Closed Principle) si DIP (The dependency Inversion Principle) din cadrul SOLID incalca principiul YAGNI? Haideti sa analizam aceasta intrebare in detaliu.

Diferite principii de design au drept obiectiv rezolvarea unor sarcini contradictorii la nivel de software design. Se poate spune ca diferite principii influenteaza design-ul in anumite directii si ca trebuie sa gasim vectorul potrivit pentru fiecare situatie. Principiul SRP (The Single Responsibility Principle) ne orienteaza spre o solutie simpla in timp ce principiul OCP ne trimite catre izolarea componentelor, iar principiul DIP are drept scop construirea unor relatii corecte intre tipuri.

Respectarea unui anumit principiu poate sa duca la incalcarea unui alt principiu. Spre exemplu, orice mostenire poate sa fie vazuta ca o incalcare a SRP, din moment ce intregul grup de clase este acum responsabil de o singura responsabilitate. Aplicarea DIP si OCP, care de cele mai multe ori implica o mostenire, poate sa duca la interfete/ clase in sistem, ceea ce duce iarasi la incalcarea principiului SRP si/sau ISP.

O asemenea relatie intre principii nu este rezolvata. De exemplu, orice mostenire poate fi vazuta ca o violare a principiului responsabilitatii unice (SRP = Single Responsibility Principle), de vreme ce un intreg grup de clase este acum legat de o singura responsabilitate (desenarea figurilor). Dar pe masura ce complexitatea sistemului creste, o ierarhie a mostenirii devine utila in termeni de SRP, din moment ce reprezentarea fiecarei figuri incepe sa devina atat de complicata incat notiunea de responsabilitate s-ar schimba si ea. Daca initial o singura responsabilitate era de a reprezenta toate figurile, acum o responsabilitate ar fi impartita intr-un set reprezentarea unui cerc, reprezentarea unui patrat etc.

YAGNI (You Arent Gonna Need it) este un principiu fundamental (am putea sa ii spunem un metaprincipiu) care te poate ajuta sa intelegi cand ar trebui sa urmezi principii / patterns / reguli si cand nu ar trebui sa faci asta.

Principiul YAGNI se bazeaza pe urmatoarele observatii:

  1. Programatorii, la fel ca majoritatea dintre noi, nu au cum sa prevada viitorul.
  2. Costurile necesare acum s-ar putea sau nu sa fie justificate pe viitor.
  3. Nici o solutie flexibila nu va fi vreodata indeajuns de flexibila.
Aceste observatii duc la urmatoarele concluzii: orice incercare de a dezvolta o solutie flexibila in primele etape de dezvoltare este sortita sa dezvolte o solutie extrem de complicata. Asta se intampla deoarece in primele etape nu stim inca de ce schimbari va avea nevoie sistemul si nu ne este clar unde putem sa avem aceasta plasa de siguranta pentru viitoarele schimbari.

Din moment ce in etapele initiale nu stim de ce flexibilitate vom avea nevoie mai exact, s-ar putea sa o implementam acolo unde nu este necesar. Putem sa dezvoltam un data layer replacement, dar datorita abstractiilor "leaky" va trebui ca sistemul sa fie dependent de o anumita baza de date sau poate nu vom avea nevoie de o asemenea caracteristica. Am putea sa dezvoltam un framework pentru analiza argumentelor din linia de comanda care sa fie folosit de o singura aplicatie, dar costul prin care acest framwork sa fie construit intr-o alta aplicatie ar fi atat de mare incat nimeni nu ar face acest lucru.

Principiul_YAGNI.jpg


Un design bun inseamna sa obtinem o solutie simpla unde schimbarile la nivel de cerinte duc la o crestere liniara a efortului.

Cel mai usor mod de a atinge acest obiectiv este prin evolutionary design: incepem prin a imparti sistemul in componente mari dar fara a adauga nivele de abstractii care nu sunt necesare. Nu vom avea nevoie de clase de baza daca nu avem cel putin 2 sau 3 descendenti. Si chiar daca ei ar putea sa apara in viitor, vom construi type hierarchy doar cand se intampla acest lucru.

Exista un test simplu pentru principiul YAGNI: straturile de abstractii (sau orice alta complicatie suplimentara) sunt justificate doar atunci cand costul pe viitor va fi mai mare ca acum.

Investitia intr-o library API bine gandita este justificata, din moment ce implementarea oricaror schimbari ar costa foarte mult. Costul de a extrage o interfata / clasa de baza dintr-o aplicatie va fi la fel azi sau intr-un an. Dar intr-un an o asemenea actiune va fi mai fezabila din punct de vedere economic si practic. Nu am lucrat fara a fi necesar inainte de momentul respectiv, si astfel ne putem concentra pe alte aspecte importante din acest moment. Mai mult decat atat intr-un an vom avea mai multe informatii si o mai buna intelegere a modului in care clasele de baza sau interfata ar trebui sa arate, deoarece se vor baza pe cerinte reale.

Rezolvarea provocarilor pe masura ce apar ne ajuta sa ne concentram pe sarcinile care sunt critice azi si sa evitam activitatile care s-ar putea sa se dovedeasca lipsite de utilitate pe viitor.

Sergey Teplyakov
Expert in .Net, ++ and Application Architecture

Daca iti place acest articol, distribuie-l si prietenilor tai!




Mai ai intrebari?
Contacteaza-ne.
Thank you.
Your request has been received.