Ragioni per l'emergere di OOP

"Ciao, Amigo! Voglio che tu capisca lo scopo di OOP. Quindi ti racconterò una storia."

C'era una volta una piccola azienda che spediva merci nello spazio...

"Come Galactic Rush?"

"Sì, come Galactic Rush. Ci lavoravano 5 persone. La prima si occupava della finanza, la seconda lavorava nel magazzino, la terza si occupava delle spedizioni, la quarta si occupava della pubblicità e la quinta supervisionava tutto."

Hanno lavorato sodo e prosperato. L'azienda aveva una buona reputazione e guadagnava molti soldi. Ogni anno il numero di ordini aumentava, quindi il CEO doveva assumere più dipendenti. Diversi per il magazzino, diversi per le spedizioni, un altro cassiere e un venditore per aumentare le vendite.

Questo è quando sono iniziati i problemi. C'era più personale e iniziarono a interferire tra loro .

Il marketer ha speso tutti i soldi per una nuova campagna pubblicitaria, senza lasciare contanti per acquistare la merce che doveva essere spedita con urgenza.

Il magazzino aveva 10 scatole con hyperdrive nuovi di zecca da spedire una volta al mese. Un corriere è volato via con un hyperdrive, causando un ritardo di un altro mese nell'ordine di 10 hyperdrive di un altro cliente. Il primo corriere semplicemente non sapeva che l'altro ordine veniva evaso dal secondo corriere.

Il nuovo assistente CEO ha inviato un corriere su una nave per acquistare merci, e tutto il resto ha aspettato la prossima nave disponibile. C'erano molte consegne urgenti, ma questo assistente gestiva solo gli acquisti e cercava di fare bene il suo lavoro. Quanto meglio una persona svolgeva i suoi doveri, tanto più interferiva con il resto .

Nell'analizzare la situazione, il CEO si è reso conto che risorse importanti come la nave, i contanti e le merci non venivano spese in modo ottimale, ma piuttosto in base al principio "primo arrivato, primo servito". Chiunque potrebbe prendere risorse per svolgere il proprio lavoro, minacciando la produttività del resto dei dipendenti e dell'azienda.

Qualcosa doveva essere fatto. L'amministratore delegato ha deciso di dividere l'azienda monolitica in diversi dipartimenti. Ha creato un reparto spedizioni, un reparto marketing, un reparto acquisti, un reparto finanziario e un reparto magazzino. Ora nessuno poteva semplicemente prendere la nave. Il capo del reparto spedizioni ha ricevuto tutte le informazioni sulla spedizione e ha consegnato la nave al corriere la cui consegna sarebbe stata più vantaggiosa per l'azienda. Inoltre, il magazzino non permetteva ai corrieri di prendere semplicemente la merce. Hanno controllato il processo. Il dipartimento finanziario non potrebbe stanziare denaro per il marketing, se sapesse che presto ci sarebbe stato un acquisto. Ogni dipartimento aveva un personaggio pubblico: il capo dipartimento. La struttura interna di ciascun dipartimento era di sua competenza.Se un corriere voleva prendere della merce, andava dal capomagazzino, non al magazzino. Quando è arrivato un nuovo ordine, è andato al capo del reparto spedizioni ( persona pubblica ), non al corriere ( persona privata ).

In altre parole, l'Amministratore Delegato ha raggruppato le risorse e le azioni in dipartimenti , vietando ad altri di interferire con le strutture interne dei dipartimenti. È stato possibile contattare solo persone specifiche.

In termini di OOP, questo non è altro che suddividere un programma in oggetti. Un programma monolitico, costituito da funzioni e variabili, viene convertito in un programma costituito da oggetti. E questi oggetti contengono variabili e funzioni.

"Aspetta un attimo. Quindi stai dicendo che il problema era che ogni dipendente aveva accesso illimitato alle risorse e poteva impartire comandi a qualsiasi altro dipendente?"

"Si, esattamente."

"Interessante. Abbiamo introdotto una piccola restrizione, ma abbiamo ricevuto più ordini. E sono riusciti a mantenere un controllo migliore su tutto".

"Sì. Dividi et impera nella sua forma più pura."

"Proprio come hai detto, dividi e conquista. È qualcosa da ricordare."