CodeGym /Curs Java /Modulul 2: Java Core /De ce avem nevoie de OOP?

De ce avem nevoie de OOP?

Modulul 2: Java Core
Nivel , Lecţie
Disponibil

"Bună, Amigo! Vreau să înțelegi scopul OOP. Așa că o să-ți spun o poveste."

A fost odată o mică companie care expedia mărfuri în spațiul cosmic...

— Ca Galactic Rush?

"Da, ca Galactic Rush. 5 oameni lucrau acolo. Primul se ocupa de finanțe, al doilea a lucrat în depozit, al treilea a făcut transportul, al patrulea se ocupa de publicitate, iar al cincilea a supravegheat totul."

Au muncit din greu și au înflorit. Compania avea o reputație bună și câștiga mulți bani. În fiecare an numărul comenzilor a crescut, așa că CEO-ul a fost nevoit să angajeze mai mulți angajați. Mai mulți pentru depozit, mai mulți pentru a face transportul, un alt casier și un marketer pentru a crește vânzările.

Aici au început problemele. Era mai mult personal și au început să se amestece unul cu celălalt .

Agentul de marketing a cheltuit toți banii pe o nouă campanie de publicitate, fără a lăsa bani cash la îndemână pentru a cumpăra bunurile care trebuiau expediate urgent.

Depozitul avea 10 cutii cu hiperdrivi noi-nouțe care urmau să fie livrate o dată pe lună. Un curier a zburat cu un hyperdrive, ceea ce a făcut ca comanda unui alt client pentru 10 hyperdrive să fie amânată încă o lună. Primul curier pur și simplu nu știa despre cealaltă comandă a fost îndeplinită de al doilea curier.

Noul director general asistent a trimis un curier pe o navă pentru a cumpăra bunuri și totul a așteptat următoarea navă disponibilă. Au fost multe livrări urgente, dar acest asistent a gestionat doar achizițiile și a încercat să-și facă treaba bine. Cu cât o persoană și-a îndeplinit mai bine sarcinile , cu atât a intervenit mai mult în restul .

Analizând situația, CEO-ul și-a dat seama că resursele importante precum nava, numerarul și bunurile nu erau cheltuite în mod optim, ci mai degrabă pe principiul „primul venit, primul servit”. Oricine ar putea lua resurse pentru a-și îndeplini munca, amenințănd productivitatea restului angajaților și a companiei.

Trebuia făcut ceva. CEO-ul a decis să împartă compania monolitică în mai multe departamente. A creat un departament de transport maritim, un departament de marketing, un departament de achiziții, un departament financiar și un departament de depozitare. Acum nimeni nu putea să ia nava. Șeful departamentului de transport maritim a primit toate informațiile de expediere și a eliberat nava curierului a cărui livrare ar fi cea mai profitabilă pentru companie. În plus, depozitul nu a lăsat curierii pur și simplu să ia mărfurile. Ei au controlat procesul. Departamentul financiar nu ar putea aloca bani pentru marketing, dacă ar ști că va avea loc o achiziție în curând. Fiecare departament avea o persoană publică: șeful de departament. Structura internă a fiecărui departament era preocuparea sa.Dacă un curier voia să ia niște mărfuri, se ducea la șeful depozitului, nu la depozit. Când a primit o nouă comandă, aceasta a mers către șeful departamentului de expediere ( persoană publică ), nu către curier ( persoană privată ).

Cu alte cuvinte, CEO-ul a grupat resursele și acțiunile în departamente și a interzis altora să interfereze cu structurile departamentale interne. Doar anumite persoane au putut fi contactate.

În ceea ce privește OOP, aceasta nu este altceva decât împărțirea unui program în obiecte. Un program monolitic, format din funcții și variabile, este convertit într-un program format din obiecte. Și aceste obiecte conțin variabile și funcții.

"Așteaptă puțin. Deci spui că problema era că fiecare angajat avea acces nerestricționat la resurse și putea emite comenzi oricărui alt angajat?"

— Da, exact.

"Interesant. Am introdus o mică restricție, dar am primit mai multe comenzi. Și au reușit să mențină un control mai bun asupra tuturor."

"Da. Împărțiți și cuceriți în forma sa cea mai pură."

"Așa cum ai spus, împarte și cucerește. Este ceva de reținut."

Comentarii
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION