Molt sovint em trobo amb desenvolupadors que no han sentit parlar dels principis de SOLID (nosaltres . - Transl.) o programació orientada a objectes (OOP), o escoltat, però no els utilitzeu a la pràctica. Aquest article descriu els avantatges dels principis de POO que ajuden el desenvolupador en el seu treball diari. Alguns d'ells són coneguts, d'altres no tant, per la qual cosa l'article serà útil tant per a programadors principiants com per a programadors ja experimentats.
Recordem: per a tots els lectors de "Habr": un descompte de 10 rubles en inscriure's a qualsevol curs de Skillbox amb el codi promocional "Habr".
Skillbox recomana: Curs educatiu en línia .
SEC (No et repeteixis)
Un principi bastant senzill, l'essència del qual es desprèn del nom: "No et repeteixis". Per a un programador, això significa la necessitat d'evitar codi duplicat, així com la capacitat d'utilitzar l'abstracció en el treball.
Si hi ha dues seccions que es repeteixen al codi, s'han de combinar en un sol mètode. Si s'utilitza un valor codificat més d'una vegada, val la pena convertir-lo en una constant pública.
Això és necessari per simplificar el codi i facilitar-ne el manteniment, que és la tasca principal de la POO. Tampoc hauríeu d'abusar del sindicat, ja que el mateix codi no passarà el control tant amb OrderId com SSN.
Canvia l'encapsulació
Els productes de programari de la majoria de les empreses estan en constant evolució. Això vol dir que el codi s'ha de canviar, s'ha de mantenir. Podeu fer-vos la vida més fàcil amb l'encapsulació. Això us permetrà provar i mantenir de manera més eficaç la vostra base de codi existent. .
Si esteu escrivint en Java, aleshores .
El principi d'obertura / proximitat
Aquest principi es pot recordar fàcilment llegint la següent afirmació: "Les entitats de programari (classes, mòduls, funcions, etc.) haurien d'estar obertes per a extensió, però tancades per a modificacions". A la pràctica, això vol dir que poden permetre que es modifiqui el seu comportament sense canviar el codi font.
El principi és important quan els canvis al codi font requereixen revisions, proves d'unitat i altres procediments. El codi que obeeix al principi obert/tancat no canvia quan s'amplia, de manera que hi ha molts menys problemes.
Aquí teniu un exemple de codi que viola aquest principi.
Si necessiteu canviar-hi alguna cosa, trigarà molt de temps, perquè haureu de canviar totes les parts del codi que tenen connexió amb el fragment desitjat.
Per cert, l'obertura-tancament és un dels principis de SOLID.
Principi de responsabilitat única (SRP)
Un altre principi del conjunt SOLID. Diu que "només hi ha una raó que porta a un canvi de classe". La classe només té una tasca. Pot tenir diversos mètodes, però cadascun d'ells només s'utilitza per resoldre un problema comú. Tots els mètodes i propietats només haurien de servir per això.
El valor d'aquest principi és que afluixa el vincle entre una única peça de programari i el codi. Afegir més d'una funcionalitat a una classe introdueix una relació entre les dues funcions. Així, si canvies un d'ells, hi ha una gran possibilitat de fer malbé el segon, relacionat amb el primer. I això significa augmentar els cicles de proves per tal d'identificar tots els problemes amb antelació.
Principi d'inversió de dependència (DIP)
L'anterior és un exemple de codi on l'AppManager depèn de l'EventLogWriter, que al seu torn està estretament relacionat amb l'AppManager. Si necessiteu una manera diferent de mostrar la notificació, ja sigui un push, un SMS o un correu electrònic, heu de canviar la classe AppManager.
El problema es pot resoldre amb DIP. Per tant, en lloc d'AppManager, demanem un EventLogWriter, que s'injectarà mitjançant el marc.
DIP fa possible substituir fàcilment mòduls individuals per altres canviant el mòdul de dependència. Això fa possible canviar un mòdul sense afectar els altres.
Composició en comptes d'herència
Les dues maneres principals de reutilitzar el codi són l'herència i la composició, cadascuna amb els seus avantatges i desavantatges. La segona se sol preferir perquè és més flexible.
La composició us ofereix la possibilitat de canviar el comportament d'una classe en temps d'execució mitjançant la configuració de les seves propietats. En implementar interfícies, s'utilitza el polimorfisme, que dóna una implementació més flexible.
Fins i tot "Java efectiva" Joshua Bloch aconsella afavorir la composició sobre l'herència.
Principi de substitució de Barbara Liskov (LSP)
Un altre principi del conjunt d'eines SOLID. Afirma que els subtipus han de ser substituïbles per un supertipus. És a dir, els mètodes i les funcions que funcionen amb una superclasse haurien de poder funcionar sense problemes amb les seves subclasses.
LSP està relacionat tant amb el Principi de Responsabilitat Única com amb el Principi de Separació de Responsabilitat. Si una classe proporciona més funcionalitat que una subclasse, aquesta última no admetrà alguna funcionalitat, violant aquest principi.
Aquí hi ha un fragment de codi que contradiu LSP.
El mètode de l'àrea (Rectangle r) calcula l'àrea d'un rectangle. El programa es bloquejarà després d'executar Square, ja que Square no és un rectangle aquí. Segons el principi LSP, les funcions que utilitzen referències a classes base haurien de poder utilitzar objectes de classes derivades sense instruccions addicionals.
Aquest principi, que és una definició específica d'un subtipus, va ser proposat per Barbara Liskov en una conferència de 1987 anomenada "Abstracció de dades i jerarquia", d'aquí el seu nom.
Principi de separació de la interfície (ISP)
Un altre principi SOLID. Segons ell, no s'hauria d'implementar una interfície que no s'utilitza. Seguir aquest principi ajuda el sistema a mantenir-se flexible i refactorable quan es fan canvis en la lògica de treball.
Molt sovint, aquesta situació es produeix quan la interfície conté diverses funcionalitats alhora i el client només en necessita una.
Com que escriure una interfície és una tasca complexa, un cop finalitzada la feina, canviar-la sense trencar res serà un problema.
L'avantatge del principi ISP a Java és que tots els mètodes s'han d'implementar primer, i només després poden ser utilitzats per les classes. Per tant, el principi permet reduir el nombre de mètodes.
Programació per a una interfície, no una implementació
Aquí tot queda clar pel nom. L'aplicació d'aquest principi condueix a un codi flexible que pot funcionar amb qualsevol implementació d'interfície nova.
Hauríeu d'utilitzar un tipus d'interfície per a variables, tipus de retorn o el tipus d'argument d'un mètode. Un exemple és utilitzar SuperClass en lloc de SubClass.
Això és:
Llista de números= getNumbers();
Però no:
ArrayList nombres = getNumbers();
Aquí teniu una implementació pràctica del que s'ha dit anteriorment.
Principi de delegació
Un exemple comú són els mètodes equals() i hashCode() a Java. Quan cal comparar dos objectes, aquesta acció es delega a la classe adequada en lloc de la classe client.
L'avantatge del principi és que no hi ha duplicació de codi i és relativament fàcil canviar el comportament. També s'aplica a la delegació d'esdeveniments.
Tots aquests principis us permeten escriure un codi més flexible, bonic i fiable amb alta cohesió i baix acoblament. Per descomptat, la teoria és bona, però perquè un desenvolupador comenci a utilitzar realment els coneixements adquirits, cal pràctica. El següent pas després de dominar els principis de la POO pot ser l'estudi de patrons de disseny per resoldre problemes comuns de desenvolupament de programari.
Skillbox recomana:
- Curs pràctic .
- Curs aplicat en línia .
- Curs pràctic de dos anys .
Font: www.habr.com