O scurta excursie in istoria programarii, pe un mod de a intelege conceptele sale fundamentale

Acesta este primul post despre principiile SOLID si ce valori si principii au toate in comun.

1972, David Parnas

In 1972, David Parnas, un om din spatele conceptelor de incapsulare si programare modulara, a scris faimoasa sa lucrare numita „Despre criteriile care trebuie utilizate in sistemele de descompunere in module” . Acolo el a elaborat criteriile care trebuie utilizate atunci cand se decide ce bucati de cod ar trebui sa locuiasca impreuna si care ar trebui sa fie separate.

Ce este despre

ce a fost atat de revolutionar in ziarul lui Parnas? Despre ce este vorba? Ei bine, este vorba despre doua lucruri conexe.

Array

In primul rand, este vorba despre alegerea conceptelor potrivite pentru a opera. La nivel de domeniu, acestea sunt conceptele de spatiu problematic. Aceste concepte sunt intr-un grad inalt, independente unele de altele. Cand vorbiti despre achizitionarea unui articol, nu va ganditi la modul in care este stocat.

Array

Implementarea acestor concepte ar trebui sa fie independenta si una de cealalta.

La nivel de infrastructura, acestea sunt principalele decizii tehnice pe care le-ati luat. Tot codul care functioneaza cu o baza de date nu ar trebui sa fie raspandit pe tot proiectul. Este cu siguranta un singur modul.

Array

In al doilea rand, este incapsularea. Atunci cand sunt modelate conceptele de domenii descompuse corespunzator, acestea nu trebuie sa se rasfete cu raspandirea detaliilor de implementare pe o baza de cod. Este mai degraba o consecinta a unui punct anterior.

Acest principiu este aplicabil la toate nivelurile, nu doar la nivel de modul. Este vorba si despre cursuri si servicii.

Profiturile

In primul rand, daca trebuie sa faceti o schimbare, cu aceasta abordare este mai probabil ca aceasta sa fie limitata intr-un domeniu clar definit si usor de inteles. Nu va trebui sa remediati jumatate din toate clasele de proiect. Daca schimbati modul in care este achizitionat un articol, nu va trebui sa modificati codul responsabil pentru stocarea acestuia. Daca va schimbati baza de date, nu va trebui sa remediati fiecare loc care utilizeaza capacitatile unei baze de date.

In al doilea rand, este de inteles. Fiecare bucata de cod are un scop clar.

1979, Yordon si Constantin

Mai tarziu, in 1979, Yordon si Constantine au inventat termenul de coeziune in cartea lor „Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design” . A mers ca.

gradul in care elementele din interiorul unui modul apartin impreuna

Wikipedia elaboreaza un pic:

Intr-un sens, este o masura a puterii relatiei dintre metodele si datele unei clase si un anumit scop sau concept unificator servit de acea clasa. Intr-un alt sens, este o masura a puterii relatiei dintre metodele clasei si datele in sine.

Ne aduce la primul punct: ar trebui sa existe un singur astfel de scop. Al doilea punct este mai subtil. Este vorba despre conformarea unui nume de clasa la responsabilitatile sale: nivelul de abstractizare al acestor doua ar trebui sa se potriveasca. Iata un exemplu pe care l-am dat unei intrebari relevante cu privire la site-ul Q si un site de inginerie software, care ilustreaza incalcarea celui de-al doilea punct:

clasa Masina

{

functie publica __construct ()

{

}

unitate functie publica ()

{

//

}

functie publica giveFuelToEngine ()

{

}

}

Responsabilitatea masinii, scopul principal al acesteia – conducerea – nu se coreleaza cu nivelul de abstractizare a metodei da combustibil.Prin urmare, exista diferite motive pentru schimbare.

2003, Robert Martin

In 2003, Robert Martin in cartea sa „ Dezvoltare software agila, principii, modele si practici ” a declarat principiul de responsabilitate unica:

O clasa ar trebui sa aiba un singur motiv pentru schimbare.

Wikipedia spune ca Martin a bazat acest principiu pe coeziune, inspirat din cartea de analiza structurata si specificatii de sistem . Ma indoiesc. Tom DeMarco a adoptat o abordare centrata pe date, unde fluxul de date este principala preocupare. Deci, coeziunea de acolo este doar un mijloc de a permite descompunerea functionala, ceea ce este totusi bine.

2004, Eric Evans

Eric Evans, in cartea sa „ Proiectare bazata pe domeniu: abordarea complexitatii in inima software-ului ”, a introdus conceptul de agregat. Este un set de obiecte care pot fi tratate ca o singura unitate. Are o caracteristica proeminenta: agregatele se pot referi unele la altele numai de catre un identificator. Si tinand cont de faptul ca nu se poate transmite niciun depozit catre acesta, este usor sa concluzionam ca nu exista nicio modalitate ca un agregat sa functioneze asupra altor agregate din limitele sale. Comunicarea lor se poate face doar prin evenimente.

Aceasta abordare promoveaza crearea unor concepte de domeniu cu adevarat coezive, care pe langa acestea au limite explicite. Aici coeziunea a intalnit incapsularea.

Infasurandu-l

Deci, daca o clasa este coeziva, daca exista un singur scop la nivel superior, daca responsabilitatile sale sunt conforme cu numele sau, SRP ar iesi in mod natural. SRP este doar o consecinta practica, nu este un scop in sine. Obiectul coeziv care il identifica si il inzestreaza cu responsabilitati corecte este. Mai mult, intregul SOLID este doar o consecinta simplificata a implementarii principiilor fundamentale OO. Este doar o forma, nu esenta.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR