1. Storia dell'azienda
Voglio raccontarvi una storia che dimostra come l'OOP aiuta a combattere la complessità dei grandi sistemi. Questo è necessario per comprendere lo scopo di OOP .
C'era una volta una piccola azienda che forniva servizi di spedizione intergalattica...
Chiamiamolo Galaxy Rush. Impiegava 5 persone. Uno lavorava in finanza, il secondo lavorava in un magazzino, il terzo faceva le consegne, il quarto si occupava della pubblicità e il quinto gestiva l'intera impresa.
Erano dei gran lavoratori e riuscivano in tutto. L'azienda aveva una buona reputazione e guadagnava molti soldi. Ma ogni anno c'erano sempre più ordini, quindi il capo doveva assumere altri dipendenti. Molti altri per il magazzino, molti altri per le consegne, uno in più per la finanza e un altro esperto di pubblicità per espandere la quota di mercato dell'azienda.
Ed è allora che sono iniziati i problemi. C'erano più persone e cominciarono a intralciarsi a vicenda.
Il marketer spende esaurisce il conto bancario per una nuova campagna pubblicitaria, quindi non ci sono soldi per acquistare prodotti che devono essere spediti con urgenza.
Il magazzino ha 10 hyper drive nuovi di zecca che vengono spediti a un cliente una volta al mese. Un corriere è arrivato e ha portato via un hyper drive per un altro cliente, causando un ritardo di un mese per l'ordine regolare di 10 hyper drive. Il primo corriere semplicemente non sapeva che l'altro ordine era stato riempito dal secondo corriere.
Il nuovo vicedirettore invia un corriere su un'astronave per acquistare altri beni. Nel frattempo, tutti gli altri aspettano che appaia un'astronave disponibile. Ci sono tonnellate di consegne urgenti, ma questa assistente supervisiona solo gli appalti e sta cercando di fare bene il suo lavoro. Quanto meglio un dipendente svolge le sue funzioni, tanto più interferisce con il lavoro degli altri.
Analizzando la situazione, il capo si rende conto che risorse importanti come l'astronave, i contanti ei prodotti non vengono utilizzati in modo ottimale. Invece, sono soggetti alla regola "tu dormi, perdi". Qualsiasi dipendente potrebbe prendere una risorsa di cui tutti gli altri hanno bisogno per il proprio lavoro, mettendo così in pericolo gli altri dipendenti e l'azienda nel suo insieme.
Bisognava fare qualcosa, così il capo decise di dividere l'azienda monolitica in pochi reparti. Ha creato un reparto spedizioni, un reparto marketing, un reparto acquisti, un reparto finanza e un reparto inventario. Nessuno poteva più semplicemente prendere l'astronave. Il capo del reparto spedizioni ha ricevuto tutte le informazioni sulle consegne e ha affidato la spedizione al corriere con l'ordine più redditizio. Inoltre, il magazzino non consentiva ai corrieri di prendere semplicemente le merci che desideravano. Invece, il prelievo dei prodotti dal magazzino è diventato un processo controllato. Il dipartimento finanziario non rilascerebbe fondi per una campagna di marketing se sapesse che presto ci sarebbe stato un acquisto. Ogni dipartimento aveva un volto pubblico: il capo dipartimento.La struttura interna di ogni dipartimento era un'attività a sé stante. Se un corriere voleva ritirare i prodotti, andava dal responsabile del magazzino, non al magazzino. Se è arrivato un nuovo ordine, è stato ricevuto dal responsabile del reparto spedizioni ( public-facing representative) e non da un corriere ( someone not authorized to interact with the other departments).
In altre parole, il capo ha consolidato le risorse e le azioni che coinvolgono le risorse in gruppi (dipartimenti) e ha anche vietato ad altri di interferire con le strutture interne dei dipartimenti. Le interazioni interdipartimentali dovevano passare attraverso una persona specifica.
Dal punto di vista di OOP , questo non è altro che dividere il programma in oggetti. Un programma monolitico di metodi e variabili diventa un programma composto da oggetti. E gli oggetti hanno variabili e metodi.
Il problema era che qualsiasi dipendente poteva lavorare con qualsiasi risorsa e impartire comandi a qualsiasi altro dipendente, il tutto senza supervisione o controlli. Abbiamo imposto una piccola restrizione, ma ottenuto più ordine. E siamo stati anche in grado di controllare meglio tutto.
Questo è divide et impera nella sua forma più pura.
2. Come vengono creati i programmi
Voglio toccare un altro punto importante che rivela un altro vantaggio dell'OOP . Vedi che i programmi sono più simili agli animali che agli edifici? Non sono costruiti. Sono cresciuti. Lo sviluppo è cambiamento continuo. Nella costruzione, puoi avere un buon piano e seguirlo con precisione. Questo non è il caso dello sviluppo software.
Molto spesso nella programmazione, non puoi fare qualcosa nel modo in cui lo avevi originariamente previsto e devi rielaborare molto. Le esigenze dei clienti cambiano ancora più spesso.
Ma cosa succede se il cliente ha fornito una specifica molto precisa? Questo rende le cose ancora peggiori. Dai un'occhiata a cosa succede con il prodotto nel tempo.
Il successo del prodotto porterà il cliente a voler rilasciare una nuova versione, e poi un'altra e un'altra ancora. E, naturalmente, tutto ciò che devi fare è aggiungere "piccole modifiche" al prodotto esistente. Quindi puoi vedere che lo sviluppo del prodotto è una sequenza di cambiamenti costanti. Solo la scala temporale è diversa. Una nuova versione può essere rilasciata una volta alla settimana, una volta al mese o una volta ogni sei mesi.
E quale conclusione possiamo trarre da tutto questo? La struttura interna del prodotto deve essere mantenuta in modo da consentire modifiche significative (e minori) con una minima rielaborazione.
Coesione dell'oggetto
Ma farlo è più difficile che decidere di farlo. Abbiamo già detto che un programma è costituito da oggetti che interagiscono tra loro. Disegniamo tutti gli oggetti del nostro programma sulla lavagna, rappresentandoli per punti. E disegniamo frecce da ogni oggetto (punto) a tutti gli altri oggetti (punti) con cui interagisce.
Ora combineremo gli oggetti (punti) in gruppi. I punti dovrebbero essere raggruppati se le connessioni tra loro sono molto più intense di quelle con altri punti. Se la maggior parte delle frecce da un punto va verso altri punti nel proprio gruppo, allora i gruppi sono stati formati correttamente. Diciamo che i punti all'interno di un gruppo hanno un'elevata coesione mentre i punti in gruppi diversi hanno una coesione inferiore.
Principio dell'accoppiamento libero
Esiste un "principio di accoppiamento libero". Un programma è diviso in più parti, che spesso sono strati. La logica di questi strati/parti è strettamente accoppiata alla loro struttura interna e molto debolmente accoppiata ad altri strati/parti. Le interazioni tra strati sono generalmente molto regolate. Un livello potrebbe fare riferimento al secondo livello e utilizzare solo un piccolo sottoinsieme delle sue classi. Questo è il principio di "dividere l'azienda in reparti" che abbiamo visto prima, ma su scala più ampia.
Il risultato è che possiamo riorganizzare un dipartimento secondo necessità per aumentarne l'efficacia e possiamo assumere ancora più persone per il dipartimento, e fintanto che non cambiamo il protocollo di interazione con gli altri nostri dipartimenti, tutte le modifiche apportate saranno rimanere locale. Nessuno deve reimparare nulla. Non è necessario rielaborare l'intero sistema. Ogni dipartimento può eseguire questo tipo di ottimizzazione interna se i meccanismi per l'interazione interdipartimentale sono ben scelti.
Scelto bene. Ma cosa succede se non vengono scelti bene? Quindi la capacità di cambiamento si esaurisce rapidamente e dovrai rifare l'intero sistema. Questo deve essere fatto di volta in volta. Non puoi prevedere il futuro, ma puoi ridurre al minimo il numero di ripetizioni.
Principio di astrazione
Scegliere come sono strutturati i dipartimenti e come interagiscono è il " principio di astrazione ". Nella programmazione, viene utilizzato per determinare il modo migliore per suddividere un programma in parti costituenti e come queste parti dovrebbero interagire. Possiamo riapplicare il principio, dividendo le parti risultanti in parti, finché non abbiamo suddiviso il programma in singole classi.
Nascondere la struttura interna di queste parti e limitare rigorosamente le interazioni con altre parti è l'incapsulamento . L'incapsulamento e l'astrazione sono i capisaldi dell'OOP . Un buon programma deve seguire questi due principi. In futuro esamineremo il resto dei principi ed esploreremo i vantaggi che offrono.