Introduzione

Robert L. Glass ha sostenuto che la pratica precede la teoria. Soprattutto nello sviluppo software, la pratica è un campo tipicamente in anticipo rispetto alla teoria, e gli sviluppatori ottengono il massimo quando si sporcano le mani creando codice concreto. Pertanto, metteremo da parte teoria e concetti per il momento e daremo un'occhiata a un semplice programma.

Implementare un'applicazione di vendita di biglietti

• Stiamo programmando un piccolo evento per promuovere un piccolo teatro.
  • Contenuto dell'evento: inviando inviti gratuiti per lo spettacolo agli spettatori scelti tramite estrazione a sorte.
• Dobbiamo separare gli spettatori che hanno vinto l'evento da quelli che non hanno vinto.
  • Spettatori vincitori dell'evento: scambia l'invito con un biglietto.
  • Spettatori che non hanno vinto l'evento: acquista un biglietto pagando.

Codice di esercitazione: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

Qual è il problema?

Robert Martin descrive tre funzioni che un modulo software (indipendentemente dalle dimensioni, come una classe, un pacchetto o una libreria, qualsiasi elemento che compone un programma) dovrebbe avere.

• Funziona correttamente durante l'esecuzione.
• Esiste per essere modificato.
  • La modifica dovrebbe essere possibile con un semplice lavoro.
• Comunicare con le persone che leggono il codice.
  • Dovrebbe essere facile da leggere e capire per gli sviluppatori.

La precedente applicazione di vendita di biglietti soddisfa il primo vincolo di esecuzione corretta, ma non soddisfa gli obiettivi di facilità di modifica e comunicazione.

Codice che non soddisfa le aspettative

Diamo un'occhiata al motivo per cui non soddisfa l'obiettivo della comunicazione.

• Cosa fa il metodo enter() della classe Theater
  • Il teatro controlla la borsa dello spettatore per vedere se contiene un invito.
  • Se la borsa contiene un invito, dice al venditore di spostare il biglietto che è conservato alla biglietteria nella borsa dello spettatore.
  • Se la borsa non contiene un invito, toglie denaro dalla borsa dello spettatore pari al costo del biglietto, compra il biglietto e lo mette nella borsa.
• Dal punto di vista dello spettatore, il teatro, una terza parte, deve guardare e rovistare nella borsa, prendere i soldi e mettere il biglietto.
• Dal punto di vista del venditore, il teatro, una terza parte, deve guardare e manipolare il valore dei biglietti e del denaro nella biglietteria senza permesso.
• Un codice comprensibile è un codice che non devia troppo dalle nostre aspettative, e il teatro sopra menzionato devia dalle nostre aspettative.
  • Lo spettatore dovrebbe prendere i soldi dalla propria borsa e pagare il venditore per ottenere il biglietto.
  • Il venditore dovrebbe prendere il biglietto direttamente dalla biglietteria e consegnarlo allo spettatore, e ricevere i soldi dallo spettatore e conservarli alla biglietteria.
• Inoltre, per capire il metodo enter(), dobbiamo ricordare molti dettagli.
  • Audience ha un Bag.
  • Bag contiene denaro e biglietti.
  • TiketSellet vende biglietti da TicketOffice e TicketOffice conserva denaro e biglietti.

Codice vulnerabile alle modifiche

Il metodo enter() assume due condizioni.

• Lo spettatore porta sempre una borsa per conservare denaro e inviti.
• Il venditore vende biglietti solo dalla biglietteria.

E se così non fosse?

• Lo spettatore potrebbe non avere una borsa.
• Lo spettatore potrebbe usare una carta di credito invece del denaro.
• Il venditore potrebbe vendere biglietti al di fuori della biglietteria.

Ad esempio, per soddisfare la prima richiesta, dobbiamo eliminare l'oggetto Bag di Audience e modificare il metodo enter() della classe Theater. Questo perché la classe Theater dipende eccessivamente dal fatto che lo spettatore abbia una borsa e che il venditore venda biglietti solo dalla biglietteria. Se uno qualsiasi di questi dettagli cambia, dobbiamo modificare sia la classe interessata (es. Theater) che le classi su cui dipende.

Questo è un problema relativo alla dipendenza tra gli oggetti e la dipendenza implica un impatto sulla modifica. Tuttavia, l'obiettivo della progettazione orientata agli oggetti è costruire una comunità di oggetti che collaborano tra loro, quindi invece di eliminare completamente la dipendenza, dobbiamo mantenere ilminimo di dipendenzenecessarie per implementare le funzionalità dell'applicazione ed eliminare le dipendenze non necessarie.

Quando la dipendenza tra gli oggetti è eccessiva, si dice che illivello di accoppiamento è alto, e maggiore è il livello di accoppiamento tra due oggetti, maggiore è la probabilità che cambino insieme. Pertanto, l'obiettivo della progettazione è ridurre il livello di accoppiamento tra gli oggetti per ottenere una progettazione facilmente modificabile.

Migliorare la progettazione

Theater non ha bisogno di sapere che lo spettatore ha una borsa e che il venditore vende biglietti dalla biglietteria. Theater vuole solo che lo spettatore entri nel teatro. Pertanto, dobbiamo rendere lo spettatore e il venditore entità autonome in modo che possano gestire il denaro e l'invito nella borsa dello spettatore e il venditore gestisca i biglietti e le tariffe di vendita della biglietteria da soli.

Aumentare l'autonomia

Un oggetto che svolge solo attività strettamente correlate e delega attività non correlate ad altri oggetti è considerato ad alto livello di coesione. Creando oggetti autonomi che gestiscono i propri dati, possiamo ridurre l'accoppiamento e aumentare la coesione.

Procedurale vs. orientato agli oggetti

• Procedurale
  • Il metodo enter() di Theater è un processo e Audience, TicketSeller, Bag, TicketOffice sono dati.
  • Il metodo di posizionamento dei processi e dei dati in moduli separati è chiamato programmazione procedurale.
  • Ci sono molti codici che vanno contro la nostra intuizione. (es. lo spettatore gestisce autonomamente il denaro e l'invito.)
  • È difficile limitare l'impatto della modifica dei dati.
  • La responsabilità è gestita centralmente. (Theater gestisce tutto)
• Orientato agli oggetti
  • Il metodo di posizionamento dei dati e dei processi all'interno dello stesso modulo è chiamato programmazione orientata agli oggetti.
  • Possiamo scrivere codice in linea con la nostra intuizione.
  • L'impatto della modifica dei dati può essere limitato efficacemente tramite l'incapsulamento.
  • Ogni oggetto è responsabile di se stesso.
  • 
    

Codice di esercitazione: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Può essere migliorato.

• La classe Bag della classe Audience è ancora un'entità passiva trascinata dalla classe Audience, quindi dobbiamo rendere la classe Bag un'entità autonoma.
• Anche TicketOffice della classe TicketSeller è gestita arbitrariamente da TicketSeller. Dobbiamo rendere TicketOffice un'entità autonoma.
  • Tuttavia, dopo la modifica, TicketOffice ha un accoppiamento aggiuntivo con Audience.
  • Come questo, la progettazione richiede un'attenta considerazione degli scambi. In questo caso, possiamo concordare di creare TicketOffice come un oggetto parzialmente passivo per ridurre l'accoppiamento con Audience.

Codice di esercitazione: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

Sì, è una bugia!

• Anche se sono entità passive nel mondo reale, una volta entrati nel mondo della programmazione orientata agli oggetti, tutto diventa attivo e autonomo.
• È meglio usare la personificazione per pensare agli oggetti passivi come se stessero ridendo, parlando e arrabbiandosi.

Progettazione orientata agli oggetti

Perché la progettazione è necessaria?

• La progettazione è la disposizione del codice.
• Una buona progettazione è una progettazione che svolge completamente le funzioni richieste oggi e che può accettare facilmente i cambiamenti di domani.

Progettazione orientata agli oggetti

• Un codice modificabile è un codice facile da capire.
• Il paradigma orientato agli oggetti ci aiuta a scrivere codice come vediamo il mondo.
• Gli oggetti sono entità autonome che sono responsabili dei propri dati.
• Una buona progettazione orientata agli oggetti è una progettazione che gestisce adeguatamente la dipendenza tra gli oggetti che collaborano.

Fonti

• Oggetti