Ako ste programer, vjerojatno ste naišli na kod koji izgleda kao čudovište, nemoguće ga je dodirnuti bez da se cijeli sustav sruši. Kako biste izbjegli upadanje u ovaj kaos, postoje... SOLID PrincipiSkup smjernica za dizajn koje je sastavio Robert C. Martin, poznati "Ujak Bob", temeljene na objektno orijentiranom programiranju. Nisu uklesane u kamenu, već... heuristički vodiči što nam pomaže pisati mnogo robusniji i čišći softver.
Središnja ideja je da uspješan softver s vremenom raste i postaje složeniji. Ako ne primijenimo pametnu strukturu, fleksibilnost nestaje, a održavanje postaje noćna mora. Usvajanjem ovih praksi želimo postići visoka kohezija a niska spojkaTo znači da svaki dio sustava radi svoj posao bez pretjeranog oslanjanja na druge, što nam omogućuje skaliranje projekta bez ikakvog napora.
Razlaganje akronima SOLID
Izraz SOLID zapravo je akronim koji je predložio Michael Feathers, a koji obuhvaća pet temeljnih smjernica. Svaka od njih bavi se uobičajenim problemom u dizajnu klasa i modula, fokusirajući se na osiguravanje da je kod jednostavan za čitanje, testiranje i održavanje dugoročno.
S: Načelo jedinstvene odgovornosti (SRP)
Ovo načelo nam govori da klasa mora imati jedan jedini razlog za promjenuJednostavno rečeno, to znači da svaka komponenta treba obavljati jedan, specifičan zadatak. Ako imate klasu koja upravlja korisničkim podacima i također je odgovorna za njihovo spremanje u bazu podataka i slanje e-poruka dobrodošlice, imate problem kohezije.
Kada klasa radi previše stvari, postaje teško za testiranje i održavanjeIdealno bi bilo da odgovornosti budu podijeljene u različite klase. Na primjer, mogli biste imati jednu klasu User za model, a UserRepository za upornost i NotificationService za obavijesti. Na taj način, ako promijenite mehanizam baze podataka, ne morate dirati logiku e-pošte.
O: Princip otvorenog/zatvorenog (OCP)
Premisa ovdje je da kod mora biti Otvoreno za proširenje, ali zatvoreno za modifikacijeOvo zvuči kao brza riječ, ali u osnovi znači da biste trebali moći dodavati nove značajke bez potrebe za mijenjanjem koda koji već radi i već je testiran.
Da bismo to postigli, obično se oslanjamo na sučelja i apstraktne klaseUmjesto popunjavanja metode naredbama if o switch Za rukovanje različitim vrstama objekata stvorili smo zajedničku bazu. Na taj način, ako sutra trebate dodati novu vrstu funkcionalnosti, jednostavno stvarate novu podklasu koja implementira ugovor, čime se izbjegava rizik od uvođenja pogrešaka u jezgru sustava.
L: Liskovljev princip supstitucije (LSP)
Nazvan po Barbari Liskov, ovaj princip kaže da izvedene klase moraju biti sposobne zamijeniti njihove bazne klase bez promjene integriteta programa. Ako imate klasu A i podklasu B, trebali biste moći koristiti B bilo gdje gdje biste očekivali A bez da se sustav ponaša nepravilno.
Uobičajena pogreška je stvaranje prisilnih hijerarhija. Ako podklasa ne može izvršiti sve radnje svoje nadklase, vjerojatno kršite ovaj princip. Pridržavanje njega osigurava da je softver ponovno iskoristiv i predvidljiv, budući da poštujemo ugovor koji je uspostavila roditeljska klasa.
I: Princip segregacije sučelja (ISP)
Ovo načelo nas upozorava da kupci ne bi trebali biti prisiljeni oslanjati se na sučelja koja ne koriste. Mnogo je bolje imati nekoliko malih i specifičnih sučelja nego jedno, glomazno, generičko sučelje koje prisiljava implementaciju nepotrebnih metoda.
Zamislite sučelje Ave s metodama volar() y nadar()Ako kreirate razred Pinguino, bili biste prisiljeni implementirati volar() iako pingvin ne leti. Rješenje je segregacija: stvaranje AveVoladora a AveNadadoraDakle, svaka klasa implementira samo ono što ti stvarno treba.
D: Princip inverzije ovisnosti (DIP)
Konačno, DIP ukazuje na to da moduli visoke razine ne bi trebali ovisiti o modulima niske razine; oba bi trebala ovise o apstrakcijamaU osnovi, to nam govori da se ne bismo trebali oslanjati na specifične klase, već na sučelja.
Na primjer, klasa poslovne logike ne bi trebala izravno ovisiti o određenoj SQL klasi. Ako ovisi, promjena baza podataka zahtijevala bi prepisivanje logike. Ispravan pristup je stvaranje sučelja. Conexion i da poslovna logika koristi to sučelje. Dakle, sustav je puno fleksibilniji i odvojeniji, što uvelike olakšava izvođenje testova korištenjem simulacija.
Prednosti i izazovi implementacije SOLID-a
Usvajanje ovog pristupa donosi ogromne koristi. Prvo, Održavanje vrtoglavo rasteBudući da promjene na jednom dijelu sustava ne utječu na ostatak, timska suradnja je glatkija jer je kod modularan i strukturiran, što sprječava preklapanje programera pri radu na različitim modulima.
Još jedna jaka strana je jednostavnost testiranjaOdvojenim odgovornostima i ubrizgavanjem ovisnosti možemo izolirati svaku komponentu i provjeriti da ispravno radi bez potrebe za prekidom rada cijelog produkcijskog okruženja. To drastično smanjuje pojavu grešaka u kasnijim fazama.
Međutim, nije sve bajno i lijepo. Za novopridošle može postojati strma krivulja učenja I postoji opasnost od pretjeranog dizajniranja. Ponekad, pokušavajući strogo primijeniti SOLID principe na mali projekt, završimo stvarajući desetke nepotrebnih sučelja i klasa koje kompliciraju kod umjesto da ga pojednostave.
- Mali projekti: Ponekad su troškovi implementacije veći od koristi.
- Teška vremena: Pokretanje MVP-a može zahtijevati privremeno žrtvovanje određene arhitektonske čistoće.
- Stari kod: Refaktoriranje starih sustava može biti rizično ako se ne radi postupno.
- Ekstremne performanse: Previše slojeva apstrakcije moglo bi imati minimalan utjecaj na brzinu obrade.
Arhitektura temeljena na SOLID-u je temelj Čist kod I vrlo dobro nadopunjuje filozofiju KISS-a (Keep It Simple, Stupid). Ne radi se o slijeđenju krutih pravila, već o primjeni zdravog razuma kako bi softver bio skalabilan i s vremenom ne bi postao tehnički teret.
Svaki programer koji želi postati profesionalac trebao bi integrirati ove smjernice u svoj svakodnevni rad, shvaćajući da cilj nije teoretsko savršenstvo, već stvaranje alata koji su funkcionalan, robustan i jednostavan za razvoj bez da proces razvoja postane muka.