En el desenvolupament de programari, Disseny Orientat a Objectes té un paper crucial quan es tracta d'escriure codi flexible, escalable, mantenible i reutilitzable. Hi ha molts avantatges d'utilitzar OOD, però tots els desenvolupadors també haurien de conèixer el principi SOLID per a un bon disseny orientat a objectes en programació. El principi SOLID va ser introduït per Robert C. Martin, també conegut com a Oncle Bob i és un estàndard de codificació en programació. Aquest principi és un acrònim dels cinc principis que es donen a continuació:

• Principi de responsabilitat única (SRP)
• Principi obert/tancat
• Principi de substitució de Liskov (LSP)
• Principi de segregació de la interfície (ISP)
• Principi d'inversió de dependència (DIP)

El principi SOLID ajuda a reduir l'acoblament estret. L'acoblament estret significa que un grup de classes depenen molt les unes de les altres, cosa que hauríeu d'evitar al vostre codi.

• El contrari de l'acoblament estret és l'acoblament fluix i el vostre codi es considera un bon codi quan té classes poc acoblades.
• Les classes poc acoblades minimitzen els canvis al vostre codi, ajuden a fer que el codi sigui més reutilitzable, fàcil de mantenir, flexible i estable. Ara anem a discutir un per un aquests principis...

1. Principi de Responsabilitat Única

Aquest principi estableix que Una classe només hauria de tenir una raó per canviar el que significa que cada classe hauria de tenir una única responsabilitat o una única feina o un únic propòsit. En altres paraules, una classe hauria de tenir només una feina o propòsit dins del sistema de programari.

sharwanand

Entenem el principi de responsabilitat única utilitzant un exemple:

Imagineu un forner que s'encarrega de fer el pa. El paper del forner és centrar-se en la tasca de coure el pa, assegurant-se que el pa sigui d'alta qualitat, cuit correctament i compleixi els estàndards de la fleca.

• Tanmateix, si el forner també és responsable de gestionar l'inventari, demanar subministraments, atendre els clients i netejar la fleca, això violaria l'SRP.
• Cadascuna d'aquestes tasques representa una responsabilitat separada i, en combinar-les, l'enfocament i l'eficàcia del forner en la cocció del pa es podrien veure compromesos.
• Per adherir-se a l'SRP, la fleca podria assignar diferents rols a diferents individus o equips. Per exemple, podria haver-hi una persona o equip independent responsable de la gestió de l'inventari, un altre per demanar subministraments, un altre per atendre els clients i un altre per netejar la fleca.

2. Principi obert/tancat

Aquest principi estableix que Les entitats de programari (classes, mòduls, funcions, etc.) haurien d'estar obertes per a extensió, però tancades per a modificacions. el que significa que hauríeu de poder ampliar un comportament de classe, sense modificar-lo.

Entenem el principi obert/tancat amb un exemple:

Imagina que tens una classe trucadaPaymentProcessor>que processa els pagaments per a una botiga en línia. Inicialment, elPaymentProcessor>La classe només admet el processament de pagaments amb targetes de crèdit. Tanmateix, voleu ampliar la seva funcionalitat per donar suport també al processament de pagaments mitjançant PayPal.

En lloc de modificar l'existentPaymentProcessor>classe per afegir suport de PayPal, podeu crear una nova classe anomenadaPayPalPaymentProcessor>que s'estén elPaymentProcessor>classe. D'aquesta manera, elPaymentProcessor>La classe roman tancada per modificacions però oberta per a ampliació, seguint el principi d'obert-tancat

arbre de cerca binari vs arbre binari

3. Principi de substitució de Liskov

El principi va ser introduït per Barbara Liskov el 1987 i segons aquest principi Les classes derivades o secundaries han de ser substituïdes per les seves classes base o pares . Aquest principi assegura que qualsevol classe que sigui fill d'una classe principal s'ha de poder utilitzar en lloc de la seva pare sense cap comportament inesperat.

Funció prototip de c++

Entenem el principi de substitució de Liskov utilitzant un exemple:

Un dels exemples clàssics d'aquest principi és un rectangle amb quatre costats. L'alçada d'un rectangle pot ser qualsevol valor i l'amplada pot ser qualsevol valor. Un quadrat és un rectangle amb la mateixa amplada i alçada. Així que podem dir que podem estendre les propietats de la classe rectangle a classe quadrada.

Per fer-ho, heu d'intercanviar la classe fill (quadrat) amb la classe pare (rectangle) per adaptar-se a la definició d'un quadrat que té quatre costats iguals, però una classe derivada no afecta el comportament de la classe pare, així que si ho feu que violarà el principi de substitució de Liskov.

4. Principi de segregació de la interfície

Aquest principi és el primer principi que s'aplica a les interfícies en lloc de les classes a SOLID i és similar al principi de responsabilitat única. Afirma que no obligueu cap client a implementar una interfície que sigui irrellevant per a ells . Aquí el vostre objectiu principal és centrar-vos a evitar la interfície grossa i donar preferència a moltes interfícies petites específiques del client. Hauríeu de preferir moltes interfícies de client en lloc d'una interfície general i cada interfície hauria de tenir una responsabilitat específica.

Entenem el principi de segregació de la interfície amb un exemple:

connectar la base de dades java

Suposem que si entres en un restaurant i ets pur vegetarià. El cambrer d'aquell restaurant us va donar la targeta del menú que inclou articles vegetarians, articles no vegetarians, begudes i dolços.

• En aquest cas, com a client, hauríeu de tenir una targeta de menú que inclogui només aliments vegetarians, no tot allò que no mengeu al vostre menjar. Aquí el menú hauria de ser diferent per a diferents tipus de clients.
• La targeta de menú comuna o general per a tothom es pot dividir en diverses targetes en lloc d'una sola. L'ús d'aquest principi ajuda a reduir els efectes secundaris i la freqüència dels canvis necessaris.

5. Principi d'inversió de dependència

El principi d'inversió de dependència (DIP) és un principi del disseny orientat a objectes que estableix això Els mòduls d'alt nivell no haurien de dependre dels mòduls de baix nivell. Tots dos haurien de dependre de les abstraccions . A més, les abstraccions no haurien de dependre dels detalls. Els detalls haurien de dependre de les abstraccions.

• En termes més senzills, el DIP suggereix que les classes haurien de basar-se en abstraccions (per exemple, interfícies o classes abstractes) en lloc d'implementacions concretes.
• Això permet un codi més flexible i desacoblat, cosa que fa que sigui més fàcil canviar les implementacions sense afectar altres parts de la base de codi.

Entendrem el principi d'inversió de dependència amb un exemple:

En un equip de desenvolupament de programari, els desenvolupadors depenen d'un sistema abstracte de control de versions (per exemple, Git) per gestionar i fer el seguiment dels canvis a la base de codi. No depenen de detalls específics de com funciona Git internament.

Això permet als desenvolupadors centrar-se a escriure codi sense necessitat d'entendre les complexitats de la implementació del control de versions.