Nello sviluppo del software, Design orientato agli oggetti gioca un ruolo cruciale quando si tratta di scrivere codice flessibile, scalabile, manutenibile e riutilizzabile. Ci sono così tanti vantaggi nell'usare OOD, ma ogni sviluppatore dovrebbe anche conoscere il principio SOLID per una buona progettazione orientata agli oggetti nella programmazione. Il principio SOLID è stato introdotto da Robert C. Martin, noto anche come Uncle Bob ed è uno standard di codifica nella programmazione. Questo principio è l’acronimo dei cinque principi riportati di seguito:

• Principio di responsabilità unica (SRP)
• Principio aperto/chiuso
• Principio di sostituzione di Liskov (LSP)
• Principio di segregazione dell'interfaccia (ISP)
• Principio di inversione delle dipendenze (DIP)

Il principio SOLID aiuta a ridurre l'accoppiamento stretto. L'accoppiamento stretto significa che un gruppo di classi è fortemente dipendente l'uno dall'altro, cosa che dovresti evitare nel tuo codice.

• L'opposto dell'accoppiamento stretto è l'accoppiamento lento e il codice è considerato un buon codice quando ha classi ad accoppiamento lento.
• Le classi liberamente accoppiate riducono al minimo le modifiche nel codice, aiutano a rendere il codice più riutilizzabile, gestibile, flessibile e stabile. Ora discutiamo uno per uno di questi principi…

1. Principio di responsabilità unica

Questo principio lo afferma Una classe dovrebbe avere un solo motivo per cambiare il che significa che ogni classe dovrebbe avere un’unica responsabilità, un unico lavoro o un unico scopo. In altre parole, una classe dovrebbe avere un solo lavoro o scopo all'interno del sistema software.

accendi Java

Comprendiamo il principio di responsabilità unica utilizzando un esempio:

Immagina un fornaio responsabile della cottura del pane. Il ruolo del fornaio è quello di concentrarsi sul compito di cuocere il pane, garantendo che il pane sia di alta qualità, cotto correttamente e soddisfi gli standard del panificio.

• Tuttavia, se il fornaio fosse anche responsabile della gestione dell’inventario, dell’ordinazione delle forniture, del servizio ai clienti e della pulizia del panificio, ciò violerebbe l’SRP.
• Ciascuno di questi compiti rappresenta una responsabilità separata e, combinandoli, l’attenzione e l’efficacia del fornaio nella cottura del pane potrebbero essere compromesse.
• Per aderire all'SRP, il panificio potrebbe assegnare ruoli diversi a diversi individui o team. Ad esempio, potrebbe esserci una persona o un team separato responsabile della gestione dell'inventario, un altro per ordinare le forniture, un altro per servire i clienti e un altro per pulire la panetteria.

2. Principio Aperto/Chiuso

Questo principio lo afferma Le entità software (classi, moduli, funzioni, ecc.) dovrebbero essere aperte per l'estensione, ma chiuse per la modifica il che significa che dovresti essere in grado di estendere il comportamento di una classe, senza modificarlo.

numero palindromo

Comprendiamo il principio di apertura/chiusura utilizzando un esempio:

Immagina di avere una classe chiamataPaymentProcessor>che elabora i pagamenti per un negozio online. Inizialmente, ilPaymentProcessor>class supporta solo l'elaborazione dei pagamenti tramite carte di credito. Tuttavia, desideri estendere le sue funzionalità per supportare anche l'elaborazione dei pagamenti tramite PayPal.

Invece di modificare l'esistentePaymentProcessor>class per aggiungere il supporto PayPal, puoi creare una nuova classe chiamataPayPalPaymentProcessor>che estende ilPaymentProcessor>classe. In questo modo, ilPaymentProcessor>la classe rimane chiusa per modifiche ma aperta per estensioni, aderendo al principio Aperto-Chiuso

3. Principio di sostituzione di Liskov

Il principio è stato introdotto da Barbara Liskov nel 1987 e secondo questo principio Le classi derivate o figlie devono essere sostituibili con le rispettive classi base o genitori . Questo principio garantisce che qualsiasi classe figlia di una classe genitore sia utilizzabile al posto della classe genitore senza alcun comportamento imprevisto.

Comprendiamo il principio di sostituzione di Liskov usando un esempio:

Uno degli esempi classici di questo principio è un rettangolo con quattro lati. L'altezza di un rettangolo può essere qualsiasi valore e la larghezza può essere qualsiasi valore. Un quadrato è un rettangolo con uguale larghezza e altezza. Quindi possiamo dire che possiamo estendere le proprietà della classe rettangolo alla classe quadrata.

Per fare ciò devi scambiare la classe figlia (quadrata) con la classe genitore (rettangolo) per adattarla alla definizione di un quadrato con quattro lati uguali ma una classe derivata non influenza il comportamento della classe genitore quindi se lo farai che violerà il principio di sostituzione di Liskov.

4. Principio di segregazione delle interfacce

Questo principio è il primo che si applica alle interfacce invece che alle classi in SOLID ed è simile al principio di responsabilità unica. Lo afferma non forzare nessun client a implementare un'interfaccia per lui irrilevante . Qui il tuo obiettivo principale è concentrarti sull'evitare un'interfaccia pesante e dare la preferenza a molte piccole interfacce specifiche del cliente. Dovresti preferire molte interfacce client piuttosto che un'interfaccia generale e ciascuna interfaccia dovrebbe avere una responsabilità specifica.

bloccare gli annunci su YouTube Android

Comprendiamo il principio di segregazione dell'interfaccia utilizzando un esempio:

Supponiamo che tu entri in un ristorante e tu sia puro vegetariano. Il cameriere di quel ristorante ti ha dato la carta del menu che include piatti vegetariani, piatti non vegetariani, bevande e dolci.

• In questo caso, come cliente, dovresti avere una carta menu che includa solo piatti vegetariani, non tutto ciò che non mangi nel tuo cibo. Qui il menu dovrebbe essere diverso per i diversi tipi di clienti.
• La carta del menù comune o generale per tutti può essere suddivisa in più carte invece che in una sola. L'utilizzo di questo principio aiuta a ridurre gli effetti collaterali e la frequenza dei cambiamenti richiesti.

5. Principio di inversione delle dipendenze

Il Principio di Inversione di Dipendenza (DIP) è un principio nella progettazione orientata agli oggetti che afferma questo I moduli di alto livello non dovrebbero dipendere dai moduli di basso livello. Entrambi dovrebbero dipendere da astrazioni . Inoltre, le astrazioni non dovrebbero dipendere dai dettagli. I dettagli dovrebbero dipendere dalle astrazioni.

• In termini più semplici, il DIP suggerisce che le classi dovrebbero fare affidamento su astrazioni (ad esempio, interfacce o classi astratte) piuttosto che su implementazioni concrete.
• Ciò consente un codice più flessibile e disaccoppiato, semplificando la modifica delle implementazioni senza influire su altre parti della base di codice.

Comprendiamo il principio di inversione di dipendenza usando un esempio:

In un team di sviluppo software, gli sviluppatori dipendono da un sistema di controllo della versione astratto (ad esempio, Git) per gestire e tenere traccia delle modifiche alla base di codice. Non dipendono da dettagli specifici di come Git funziona internamente.

cambia Java

Ciò consente agli sviluppatori di concentrarsi sulla scrittura del codice senza dover comprendere le complessità dell'implementazione del controllo della versione.