A Giava, Principi SOLIDI sono un approccio orientato agli oggetti applicato alla progettazione della struttura del software. È concettualizzato da Robert C. Martin (noto anche come zio Bob). Questi cinque principi hanno cambiato il mondo della programmazione orientata agli oggetti e hanno anche cambiato il modo di scrivere software. Garantisce inoltre che il software sia modulare, facile da comprendere, eseguire il debug e il refactoring. In questa sezione discuteremo Principi SOLIDI in Java con il giusto esempio .
La parola SOLID acronimo di:
- Principio di responsabilità unica (SRP)
- Principio aperto-chiuso (OCP)
- Principio di sostituzione di Liskov (LSP)
- Principio di segregazione dell'interfaccia (ISP)
- Principio di inversione delle dipendenze (DIP)
Spieghiamo i principi uno per uno nel dettaglio.
Principio di responsabilità unica
Lo afferma il principio della responsabilità unica ogni classe Java deve eseguire una singola funzionalità . L'implementazione di più funzionalità in una singola classe mescola il codice e, se è necessaria una modifica, può influenzare l'intera classe. Preciso il codice e il codice può essere facilmente mantenuto. Cerchiamo di comprendere il principio di responsabilità unica attraverso un esempio.
Supponiamo, Alunno è una classe con tre metodi vale a dire stampaDettagli(), calcolaPercentuale(), E aggiungiStudente(). Pertanto, la classe Studente ha tre responsabilità: stampare i dettagli degli studenti, calcolare le percentuali e il database. Utilizzando il principio di responsabilità unica, possiamo separare queste funzionalità in tre classi separate per raggiungere l'obiettivo del principio.
10 di 100,00
Student.java
public class Student { public void printDetails(); { //functionality of the method } pubic void calculatePercentage(); { //functionality of the method } public void addStudent(); { //functionality of the method } } Il frammento di codice sopra riportato viola il principio di responsabilità unica. Per raggiungere l'obiettivo del principio, dovremmo implementare una classe separata che esegua solo una singola funzionalità.
Student.java
public class Student { public void addStudent(); { //functionality of the method } } PrintStudentDetails.java
quante città ci sono in noi
public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } Percentuale.java
public class Percentage { public void calculatePercentage(); { //functionality of the method } } Pertanto, abbiamo raggiunto l'obiettivo del principio di responsabilità unica separando la funzionalità in tre classi separate.
Principio aperto-chiuso
L'applicazione o il modulo entità i metodi, le funzioni, le variabili, ecc. Il principio aperto-chiuso lo afferma in base ai nuovi requisiti il modulo dovrebbe essere aperto per l'estensione ma chiuso per la modifica. L'estensione ci consente di implementare nuove funzionalità al modulo. Capiamo il principio attraverso un esempio.
Supponiamo, Informazioni sul veicolo è una classe e ha il metodo numero del veicolo() che restituisce il numero del veicolo.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } Se vogliamo aggiungere un'altra sottoclasse denominata Truck, aggiungiamo semplicemente un'altra istruzione if che viola il principio aperto-chiuso. L'unico modo per aggiungere la sottoclasse e raggiungere l'obiettivo principale sovrascrivendo il file numero del veicolo() metodo, come abbiamo mostrato di seguito.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber() { //functionality } } public class Car extends VehicleInfo { public double vehicleNumber() { return this.getValue(); } public class Car extends Truck { public double vehicleNumber() { return this.getValue(); } Allo stesso modo, possiamo aggiungere più veicoli creando un'altra sottoclasse che si estende dalla classe dei veicoli. l'approccio non influenzerebbe l'applicazione esistente.
età rekha
Principio di sostituzione di Liskov
Il principio di sostituzione di Liskov (LSP) è stato introdotto da Barbara Liskov . Si applica all'eredità in modo tale che il le classi derivate devono essere completamente sostituibili con le loro classi base . In altre parole, se la classe A è un sottotipo della classe B, allora dovremmo essere in grado di sostituire B con A senza interrompere il comportamento del programma.
Estende il principio apertura-chiusura e si concentra anche sul comportamento di una superclasse e dei suoi sottotipi. Dovremmo progettare le classi per preservare la proprietà a meno che non abbiamo una forte ragione per fare diversamente. Capiamo il principio attraverso un esempio.
Student.java
public class Student { private double height; private double weight; public void setHeight(double h) { height = h; } public void setWeight(double w) { weight= w; } ... } public class StudentBMI extends Student { public void setHeight(double h) { super.setHeight(h); super.setWeight(w); } public void setWeight(double h) { super.setHeight(h); super.setWeight(w); } } Le classi di cui sopra violano il principio di sostituzione di Liskov perché la classe StudentBMI ha vincoli aggiuntivi, ad esempio altezza e peso che devono essere gli stessi. Pertanto, la classe Student (classe base) non può essere sostituita dalla classe StudentBMI (classe derivata).
Pertanto, la sostituzione della classe Student con la classe StudentBMI potrebbe provocare un comportamento imprevisto.
Principio di segregazione delle interfacce
Il principio afferma che le interfacce più grandi si dividono in quelle più piccole. Perché le classi di implementazione utilizzano solo i metodi richiesti. Non dovremmo forzare il cliente a utilizzare i metodi che non desidera utilizzare.
L’obiettivo del principio di segregazione dell’interfaccia è simile al principio di responsabilità unica. Capiamo il principio attraverso un esempio.
Supponiamo di aver creato un'interfaccia denominata Conversione avere tre metodi intToDouble(), intToChar(), E charToString() .
public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } L'interfaccia sopra ha tre metodi. Se vogliamo utilizzare solo un metodo intToChar(), non abbiamo altra scelta se implementare il metodo singolo. Per superare il problema, il principio ci consente di dividere l'interfaccia in tre distinte.
public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } Ora possiamo utilizzare solo il metodo richiesto. Supponiamo di voler convertire l'intero in double e il carattere in stringa, quindi utilizzeremo solo i metodi intToDouble() E charToString().
public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } Principio di inversione delle dipendenze
Il principio afferma che dobbiamo usare l'astrazione (classi e interfacce astratte) invece di implementazioni concrete. I moduli di alto livello non dovrebbero dipendere dal modulo di basso livello ma entrambi dovrebbero dipendere dall'astrazione. Perché l'astrazione non dipende dal dettaglio ma il dettaglio dipende dall'astrazione. Disaccoppia il software. Capiamo il principio attraverso un esempio.
public class WindowsMachine { //functionality } Vale la pena, se non disponiamo di tastiera e mouse, di lavorare su Windows. Per risolvere questo problema, creiamo un costruttore della classe e aggiungiamo le istanze della tastiera e del monitor. Dopo aver aggiunto le istanze, la classe è simile alla seguente:
public class WindowsMachine { public final keyboard; public final monitor; public WindowsMachine() { monitor = new monitor(); //instance of monitor class keyboard = new keyboard(); //instance of keyboard class } } Ora possiamo lavorare sulla macchina Windows con l'aiuto di tastiera e mouse. Ma dobbiamo ancora affrontare il problema. Perché abbiamo strettamente accoppiato le tre classi utilizzando la nuova parola chiave. È difficile testare la macchina Windows di classe.
Per rendere il codice liberamente accoppiato, disaccoppiamo WindowsMachine dalla tastiera utilizzando l'interfaccia Keyboard e questa parola chiave.
Tastiera.java
array di ordinamento in Java
public interface Keyboard { //functionality } WindowsMachine.java
public class WindowsMachine { private final Keyboard keyboard; private final Monitor monitor; public WindowsMachine(Keyboard keyboard, Monitor monitor) { this.keyboard = keyboard; this.monitor = monitor; } } Nel codice precedente, abbiamo utilizzato l'inserimento delle dipendenze per aggiungere la dipendenza della tastiera nella classe WindowsMachine. Pertanto, abbiamo disaccoppiato le classi.
Perché dovremmo utilizzare i principi SOLID?
- Riduce le dipendenze in modo che un blocco di codice possa essere modificato senza influenzare gli altri blocchi di codice.
- I principi intesi a rendere la progettazione più semplice e comprensibile.
- Utilizzando i principi, il sistema è manutenibile, testabile, scalabile e riutilizzabile.
- Evita la cattiva progettazione del software.
La prossima volta che progetterai un software, tieni a mente questi cinque principi. Applicando questi principi, il codice sarà molto più chiaro, verificabile e spendibile.