"Bună ziua, Amigo! Aș vrea să vă spun despre un alt beneficiu al POO. Vedeți, programele sunt mai mult ca animale decât clădiri. Nu sunt construite, sunt crescute. Dezvoltarea înseamnă schimbări constante. În construcții, puteți ai un plan bun și urmează-l până la capăt. Dar în dezvoltarea de software, nu este cazul.”

Destul de des, nu poți face ceva în modul în care ți-ai propus și trebuie să-ți reprogramezi mult programul. Și chiar mai des, cerințele clientului se schimbă.

„Dar dacă clientul ar furniza o specificație cu adevărat detaliată?”

„Uitați-vă la ceea ce se întâmplă în timp. Dacă un produs reușește, clientul va dori să lanseze o nouă versiune, apoi alta și alta. Și, desigur, va trebui să faceți câteva „ modificări mici ” la produsul existent. Deci dezvoltarea de software este o serie lungă de schimbări. Numai cadența diferă. O nouă versiune ar putea fi lansată în fiecare săptămână, o dată pe lună sau la fiecare șase luni."

Java university

„Deci ce concluzionăm din toate acestea?”

„Structura internă a produsului trebuie menținută într-un mod care să permită efectuarea unor modificări majore (și minore) cu o reluare minimă”.

"Cum faci asta?"

„Am vorbit deja despre modul în care un program este format din obiecte care interacționează între ele. Să folosim puncte groase pentru a reprezenta toate obiectele programului nostru pe tablă. Vom desena săgeți de la fiecare obiect (punct) la toate obiectele. (puncte) cu care interacționează.”

Acum să combinăm obiectele (punctele) în grupuri. Punctele aparțin aceluiași grup dacă sunt mult mai conectate între ele decât celelalte puncte. Dacă majoritatea săgeților unui punct indică punctele din grupul său, atunci am grupat corect obiectele. Se spune că punctele din același grup sunt strâns cuplate, în timp ce punctele din grupuri diferite sunt slab cuplate.

Acesta se numește „ principiul cuplarii libere ”. Un program este împărțit în mai multe părți, adesea straturi, a căror logică este puternic legată de structura lor internă și slab legată de alte straturi/părți. Interacțiunea dintre straturi este de obicei foarte compartimentată. Un strat poate apela un alt strat folosind doar un mic subset al claselor sale.

„Același principiu al „diviziunii muncii”, dar la scară mai mare?”

"Mai exact. Acest lucru ne permite să reorganizăm un departament, să-l eficientizăm și să angajăm și mai mulți oameni, iar dacă nu schimbăm protocoalele interdepartamentale, atunci toate schimbările noastre vor fi locale. Nimeni nu trebuie recalificat. Nu trebuie să reprocesez întregul sistem. Fiecare departament își poate optimiza afacerile interne în acest fel dacă mecanismele de interacțiune departamentală sunt bine alese."

"Dacă sunt aleși bine. Și dacă nu sunt aleși bine?"

„Atunci veți rămâne rapid fără „ spațiu de mișcare ” pentru a face modificări și va trebui să reluați întregul sistem. Asta se întâmplă din când în când. Nu putem prezice viitorul, dar putem minimiza numărul de ori când trebuie să rescriem programul.”

"Bine. Văd beneficiul împărțirii programului așa, dar cum intervine OOP în imagine?"

„Când alegem cum să structurăm departamentele și cum vor interacționa acestea, aplicăm „ principiul abstracției ”. În programare, abstracția este folosită pentru a determina cea mai bună modalitate de a împărți programul și modul în care părțile ar trebui să interacționeze. Acest principiu poate de asemenea, se aplică în mod repetat părților constitutive până când vom împărți programul în clase individuale.”

„Și ascunderea structurii interne a acestor părți și limitarea strictă a modului în care interacționează cu alte părți – asta este încapsularea , nu?”

"Exact. Încapsularea și abstractizarea sunt pietrele de temelie ale POO. Un program bun trebuie să adere la aceste două principii. Mai târziu vom arunca o privire asupra altor principii și vom ajunge să le înțelegem avantajele."

"Lucruri bune. Abia aștept!"