De ce avem nevoie de OOP?

1. Istoricul companiei

Vreau să vă spun o poveste care demonstrează modul în care OOP ajută la lupta cu complexitatea sistemelor mari. Acest lucru este necesar pentru a înțelege scopul OOP .

A fost odată ca niciodată o mică companie care furniza servicii de transport maritim intergalactic...

Să-i spunem Galaxy Rush. A angajat 5 persoane. Unul a lucrat în finanțe, al doilea a lucrat într-un depozit, al treilea a făcut livrările, al patrulea s-a ocupat de publicitate, iar al cincilea a gestionat întreaga întreprindere.

Au fost foarte muncitori și au reușit în toate. Compania avea o reputație bună și câștiga mulți bani. Dar în fiecare an erau tot mai multe comenzi, așa că șeful a fost nevoit să angajeze angajați suplimentari. Mai multe pentru depozit, mai multe pentru livrări, încă una pentru finanțe și un expert în publicitate suplimentar pentru a extinde cota de piață a companiei.

Și atunci au început problemele. Erau mai mulți oameni și au început să se pună în cale unul altuia.

Marketerul cheltuiește contul bancar pentru o nouă campanie de publicitate, astfel încât nu există bani pentru achiziționarea produselor care trebuie expediate urgent.

Depozitul are 10 hyper drive-uri nou-nouțe care sunt livrate unui client o dată pe lună. Un curier a zburat și a luat un hyper drive pentru un alt client, ceea ce a făcut ca comanda obișnuită pentru 10 hyper drive să fie întârziată cu o lună. Primul curier pur și simplu nu știa că cealaltă comandă a fost completată de cel de-al doilea curier.

Noul asistent manager trimite un curier pe o navă spațială pentru a cumpăra mai multe bunuri. Între timp, toți ceilalți așteaptă să apară o navă spațială disponibilă. Există tone de livrări urgente, dar această asistentă supraveghează doar achizițiile și încearcă să-și facă treaba bine. Cu cât un angajat își îndeplinește mai bine sarcinile, cu atât interferează mai mult cu munca celorlalți.

Analizând situația, șeful realizează că resurse importante precum nava spațială, numerarul și produsele nu sunt utilizate în mod optim. În schimb, ele sunt supuse regulii „amâni, pierzi”. Orice angajat ar putea lua o resursă de care toți ceilalți au nevoie pentru munca lor, punând astfel în pericol ceilalți angajați și compania în ansamblu.

Trebuia făcut ceva, așa că șeful a decis să împartă compania monolitică în câteva departamente. A creat un departament de transport maritim, un departament de marketing, un departament de achiziții, un departament financiar și un departament de inventar. Nimeni nu mai putea pur și simplu să ia nava spațială. Șeful departamentului de transport maritim a primit toate informațiile despre livrări și a eliberat nava curierului cu cea mai profitabilă comandă. În plus, depozitul nu a permis curierilor să ia pur și simplu orice mărfuri doreau. În schimb, alegerea produselor din depozit a devenit un proces controlat. Departamentul de finanțe nu ar elibera fonduri pentru o campanie de marketing dacă ar ști că va avea loc o achiziție în curând. Fiecare departament avea o singură față publică - șeful de departament.Structura internă a fiecărui departament era propria sa afacere. Dacă un curier dorea să ia produse, se ducea la șeful depozitului, nu la depozit. Dacă a venit o nouă comandă, aceasta a fost primită de șeful departamentului de expediere ( public-facing representative) și nu de un curier ( someone not authorized to interact with the other departments).

Cu alte cuvinte, șeful a consolidat resursele și acțiunile care implică resurse în grupuri (departamente) și , de asemenea, le-a interzis altora să interfereze cu structurile interne ale departamentelor. Interacțiunile interdepartamentale trebuiau să treacă printr-o anumită persoană.

Din punctul de vedere al OOP , aceasta nu este altceva decât împărțirea programului în obiecte. Un program monolitic de metode și variabile devine un program compus din obiecte. Și obiectele au variabile și metode.

Problema era că orice angajat putea lucra cu orice resursă și putea da comenzi oricărui alt angajat, totul fără supraveghere sau controale. Am impus o mică restricție, dar am realizat mai multă ordine. Și am putut, de asemenea, să controlăm mai bine totul.

Acesta este împărțiți și cuceriți în forma sa cea mai pură.

2. Cum sunt create programele

Vreau să ating un alt punct important care dezvăluie un alt avantaj al OOP . Vedeți că programele seamănă mai mult cu animalele decât cu clădirile? Nu sunt construite. Sunt crescuți. Dezvoltarea este o schimbare constantă. În construcții, puteți avea un plan bun și îl puteți urma cu precizie. Acesta nu este cazul dezvoltării de software.

Foarte des, în programare, nu poți face ceva așa cum ai intenționat inițial și trebuie să lucrezi mult. Cerințele clienților se schimbă și mai des.

Dar dacă clientul a furnizat o specificație foarte precisă? Asta înrăutăţeşte lucrurile. Aruncă o privire la ceea ce se întâmplă cu produsul în timp.

Succesul produsului îl va determina pe client să dorească să lanseze o nouă versiune, apoi alta și alta. Și, desigur, tot ce trebuie să faceți este să adăugați „mici modificări” produsului existent. Astfel, puteți vedea că dezvoltarea produsului este o secvență de schimbări constante. Doar scara de timp este diferită. O nouă versiune poate fi lansată o dată pe săptămână, o dată pe lună sau o dată la șase luni.

Și ce concluzie putem trage din toate acestea? Structura internă a produsului trebuie menținută într-un mod care să permită efectuarea unor modificări semnificative (și minore) cu reprelucrare minimă.

Coeziunea obiectelor

Dar este mai dificil să faci asta decât să te decizi să o faci. Am spus deja că un program este format din obiecte care interacționează între ele. Să desenăm pe tablă toate obiectele programului nostru, reprezentându-le prin puncte. Și să desenăm săgeți de la fiecare obiect (punct) la toate celelalte obiecte (puncte) cu care interacționează.

Acum vom combina obiectele (punctele) în grupuri. Punctele trebuie grupate dacă conexiunile dintre ele sunt mult mai intense decât cele cu alte puncte. Dacă majoritatea săgeților dintr-un punct merg la alte puncte din propriul său grup, atunci grupurile au fost formate corect. Spunem că punctele dintr-un grup au o coeziune ridicată, în timp ce punctele din diferite grupuri au o coeziune mai mică.

Principiul cuplajului liber

Există un „principiu de cuplare liberă”. Un program este împărțit în mai multe părți, care sunt adesea straturi. Logica acestor straturi/părți este strâns cuplată cu structura lor internă și foarte slab cuplată cu alte straturi/părți. Interacțiunile dintre straturi sunt de obicei foarte reglementate. Un strat s-ar putea referi la al doilea strat și poate folosi doar un mic subset al claselor sale. Acesta este principiul „împărțirii companiei în departamente” pe care l-am văzut mai devreme, dar la scară mai mare.

Rezultatul este că putem reorganiza un departament după cum este necesar pentru a-i crește eficiența și putem angaja și mai mulți oameni pentru departament, iar atâta timp cât nu schimbăm protocolul de interacțiune cu celelalte departamente ale noastre, atunci toate modificările făcute vor rămâne locală. Nimeni nu trebuie să reînvețe nimic. Nu trebuie să reluați întregul sistem. Fiecare departament poate face acest tip de optimizare internă dacă mecanismele de interacțiune interdepartamentală sunt bine alese.

Bine ales. Dar dacă nu sunt bine aleși? Apoi capacitatea de schimbare este epuizată rapid și va trebui să refaceți întregul sistem. Acest lucru trebuie făcut din când în când. Nu puteți prezice viitorul, dar puteți menține numărul de refaceri la minimum.

Principiul abstracției

Alegerea modului în care departamentele sunt structurate și modul în care acestea interacționează este „ principiul abstracției ”. În programare, este folosit pentru a determina cea mai bună modalitate de a împărți un program în părți constitutive și modul în care aceste părți ar trebui să interacționeze. Putem reaplica principiul, împărțind părțile rezultate în părți, până când vom împărți programul în clase individuale.

Ascunderea structurii interne a acestor părți și limitarea strictă a interacțiunilor cu alte părți este încapsularea . Încapsularea și abstractizarea sunt pietrele de temelie ale POO . Un program bun trebuie să respecte aceste două principii. În viitor, ne vom uita la restul principiilor și vom explora ce beneficii oferă acestea.