Kung ikaw ay isang programmer, malamang ay nakakita ka na ng code na tila isang halimaw, imposibleng hawakan nang hindi nagkaka-crash ang buong sistema. Para maiwasan ang pagkahulog sa kaguluhang ito, may mga... SOLID na PrinsipyoIsang hanay ng mga alituntunin sa disenyo na tinipon ni Robert C. Martin, ang sikat na "Uncle Bob," batay sa object-oriented programming. Hindi ito nakatakda sa simula, kundi... mga gabay na heuristiko na tumutulong sa amin na sumulat ng mas matatag at mas malinis na software.
Ang pangunahing ideya ay ang matagumpay na software ay may posibilidad na lumago at maging mas kumplikado sa paglipas ng panahon. Kung hindi tayo maglalapat ng isang matalinong istraktura, mawawala ang kakayahang umangkop at ang pagpapanatili ay magiging isang bangungot. Sa pamamagitan ng pag-aampon ng mga kasanayang ito, nilalayon naming makamit ang isang mataas na pagkakaisa at mababang pagkabitNangangahulugan ito na ang bawat bahagi ng sistema ay may kanya-kanyang ginagawa nang hindi labis na umaasa sa iba, na nagbibigay-daan sa amin upang mapalawak ang proyekto nang hindi nagpapakahirap.
Pag-unawa sa acronym na SOLID
Ang terminong SOLID ay isang akronim na iminungkahi ni Michael Feathers na sumasaklaw sa limang pangunahing alituntunin. Ang bawat isa sa mga ito ay tumutugon sa isang karaniwang problema sa disenyo ng mga klase at modyul, na nakatuon sa pagtiyak na ang code ay madaling basahin, subukan at panatilihin mahabang panahon.
S: Prinsipyo ng Isang Responsibilidad (SRP)
Sinasabi sa atin ng prinsipyong ito na ang isang klase ay dapat magkaroon ng isang dahilan lang para magbagoSa madaling salita, nangangahulugan ito na ang bawat bahagi ay dapat humawak ng isang partikular na gawain. Kung mayroon kang isang klase na namamahala sa datos ng isang user at responsable rin sa pag-save nito sa database at pagpapadala ng mga welcome email, mayroon kang problema sa cohesion.
Kapag napakaraming bagay ang ginagawa ng isang klase, nagiging mahirap subukan at panatilihinSa isip, ang mga responsibilidad ay dapat hatiin sa iba't ibang klase. Halimbawa, maaari kang magkaroon ng isang klase User para sa modelo, isang UserRepository para sa pagtitiyaga at isang NotificationService para sa mga notification. Sa ganitong paraan, kung babaguhin mo ang database engine, hindi mo na kailangang hawakan ang email logic.
O: Bukas/Saradong Prinsipyo (OCP)
Ang premisa rito ay ang code ay dapat na Bukas para sa pagpapalawak ngunit sarado para sa pagbabagoParang pabago-bagong usapan ito, pero ibig sabihin nito ay dapat kang magdagdag ng mga bagong feature nang hindi kinakailangang baguhin ang code na gumagana na at nasubukan na.
Para makamit ito, karaniwan tayong umaasa sa mga interface at abstract na mga klaseSa halip na punan ang isang pamamaraan ng mga pahayag if o switch Para mapangasiwaan ang iba't ibang uri ng mga bagay, lumikha kami ng isang karaniwang base. Sa ganitong paraan, kung kailangan mong magdagdag ng isang bagong uri ng functionality bukas, lumikha ka lamang ng isang bagong subclass na magpapatupad ng kontrata, sa gayon ay maiiwasan ang panganib ng pagpapakilala ng mga error sa core ng sistema.
L: Prinsipyo ng Pagpapalit ng Liskov (LSP)
Ipinangalan kay Barbara Liskov, ang prinsipyong ito ay nagsasaad na ang mga hinangong klase ay dapat na kayang palitan ang kanilang mga base class nang hindi binabago ang integridad ng programa. Kung mayroon kang class A at subclass B, dapat mong magamit ang B kahit saan mo inaasahan ang A nang hindi kumikilos nang pabago-bago ang sistema.
Isang karaniwang pagkakamali ang paglikha ng mga sapilitang hierarchy. Kung hindi kayang gawin ng isang subclass ang lahat ng aksyon ng superclass nito, malamang na nilalabag mo ang prinsipyong ito. Ang pagsunod dito ay tinitiyak na ang software ay magagamit muli at mahuhulaan, dahil nirerespeto namin ang kontratang itinatag ng parent class.
I: Prinsipyo ng Paghihiwalay ng Interface (ISP)
Ang prinsipyong ito ay nagbabala sa atin na ang mga customer ay hindi dapat pilitin na umasa sa mga interface na hindi nila ginagamit. Mas mainam na magkaroon ng ilang maliliit at partikular na mga interface kaysa sa isang iisa, malaki, at generic na interface na pumipilit sa pagpapatupad ng mga hindi kinakailangang pamamaraan.
Isipin ang isang interface Ave gamit ang mga pamamaraan volar() y nadar()Kung gagawa ka ng klase Pinguino, mapipilitan kang ipatupad volar() kahit na hindi lumilipad ang penguin. Ang solusyon ay ang paghihiwalay: paglikha ng isang AveVoladora at AveNadadoraKaya, ipinapatupad ng bawat klase kung ano lang talaga ang kailangan mo.
D: Prinsipyo ng Pagbabaligtad ng Dependensiya (DIP)
Panghuli, ipinapahiwatig ng DIP na ang mga high-level module ay hindi dapat umasa sa mga low-level module; pareho dapat umasa sa mga abstraksyonSa madaling salita, sinasabi nito sa atin na hindi tayo dapat umasa sa mga partikular na klase, kundi sa mga interface.
Halimbawa, ang isang business logic class ay hindi dapat direktang umasa sa isang partikular na SQL class. Kung oo, ang pagpapalit ng mga database ay mangangailangan ng muling pagsusulat ng logic. Ang tamang paraan ay ang paglikha ng isang interface. Conexion at ginagamit ng business logic ang interface na iyon. Kaya, ang sistema ay mas flexible at decoupled, na lubos na nagpapadali sa pagganap ng mga pagsubok sa pamamagitan ng paggamit ng mga mock.
Mga kalamangan at hamon ng pagpapatupad ng SOLID
Ang paggamit ng pamamaraang ito ay nagdudulot ng napakalaking benepisyo. Una, ang Tumataas nang husto ang kakayahang mapanatiliDahil ang mga pagbabago sa isang bahagi ng sistema ay hindi nakakaapekto sa iba, mas maayos ang pakikipagtulungan ng pangkat dahil ang code ay modular at nakabalangkas, na pumipigil sa mga developer na mag-overlap kapag nagtatrabaho sa iba't ibang module.
Ang isa pang matibay na punto ay ang kadalian ng pagsubokSa pamamagitan ng pagkakaroon ng magkakahiwalay na responsibilidad at dependency injection, maaari nating ihiwalay ang bawat bahagi at mapatunayan na gumagana ito nang tama nang hindi kinakailangang bawasan ang buong kapaligiran ng produksyon. Malaki ang nababawasan nito sa paglitaw ng mga bug sa mga susunod na yugto.
Gayunpaman, hindi lahat ay puno ng magandang karanasan. Para sa mga baguhan, maaaring mayroong matarik na kurba ng pagkatuto At nariyan ang panganib ng labis na disenyo. Minsan, sa pamamagitan ng mahigpit na paglalapat ng mga prinsipyo ng SOLID sa isang maliit na proyekto, nauuwi tayo sa paglikha ng dose-dosenang mga hindi kinakailangang interface at klase na nagpapakomplikado sa code sa halip na pinapasimple ito.
- Mga maliliit na proyekto: Minsan mas malaki ang gastos sa pagpapatupad kaysa sa benepisyo.
- Mga panahong mahirap: Ang paglulunsad ng isang MVP ay maaaring mangailangan ng pansamantalang pagsasakripisyo ng ilang kadalisayan ng arkitektura.
- Kodigo ng Pamana: Ang pag-refactor ng mga lumang sistema ay maaaring maging mapanganib kung hindi ito gagawin nang paunti-unti.
- Matinding pagganap: Ang napakaraming patong ng abstraksyon ay maaaring magkaroon ng kaunting epekto sa bilis ng pagproseso.
Ang pagkakaroon ng arkitekturang nakabatay sa SOLID ang pundasyon ng Malinis na Kodigo At lubos nitong napupunan ang pilosopiya ng KISS (Keep It Simple, Stupid). Hindi ito tungkol sa pagsunod sa mahigpit na mga patakaran, kundi tungkol sa paglalapat ng sentido komun upang ang software ay maging scalable at hindi maging isang teknikal na pasanin sa paglipas ng panahon.
Dapat isama ng sinumang developer na naghahangad na maging isang propesyonal ang mga alituntuning ito sa kanilang pang-araw-araw na gawain, na nauunawaan na ang layunin ay hindi ang teoretikal na pagiging perpekto, kundi ang paglikha ng mga tool na gumagana, matatag at madaling umunlad nang hindi nagiging isang paghihirap ang proseso ng pag-unlad.