Madalas ay nakakatugon ako ng mga developer na hindi nakarinig ng mga SOLID na prinsipyo (kami . β Transl.) o object-oriented programming (OOP), o narinig na ang mga ito, ngunit huwag gamitin ang mga ito sa pagsasanay. Inilalarawan ng artikulong ito ang mga benepisyo ng mga prinsipyo ng OOP na tumutulong sa developer sa kanyang pang-araw-araw na gawain. Ang ilan sa kanila ay kilala, ang iba ay hindi gaanong, kaya ang artikulo ay magiging kapaki-pakinabang para sa parehong mga nagsisimula at nakaranas ng mga programmer.
Pinapaalala namin sa iyo: para sa lahat ng mga mambabasa ng Habr - isang 10 ruble na diskwento kapag nag-enroll sa anumang kurso sa Skillbox gamit ang Habr promotional code.
Inirerekomenda ng Skillbox ang: Online na kursong pang-edukasyon .
DRY (Huwag Ulitin ang Iyong Sarili)
Isang medyo simpleng prinsipyo, ang kakanyahan nito ay malinaw sa pangalan: "Huwag ulitin ang iyong sarili." Para sa isang programmer, nangangahulugan ito ng pangangailangan na maiwasan ang duplicate na code, pati na rin ang pagkakataong gumamit ng abstraction sa kanilang trabaho.
Kung mayroong dalawang paulit-ulit na seksyon sa code, dapat silang pagsamahin sa isang paraan. Kung ang isang hardcoded na halaga ay ginamit nang higit sa isang beses, sulit itong i-convert sa isang pampublikong pare-pareho.
Ito ay kinakailangan upang gawing simple ang code at gawing mas madali ang pagpapanatili, na siyang pangunahing layunin ng OOP. Hindi mo rin dapat gamitin nang labis ang unyon, dahil ang parehong code ay hindi papasa sa pag-verify kasama ang OrderId at ang SSN.
Mga Pagbabago sa Encapsulating
Karamihan sa mga produkto ng software ng kumpanya ay patuloy na umuunlad. Nangangahulugan ito na kailangang gumawa ng mga pagbabago sa code, kailangan itong suportahan. Mapapadali mo ang iyong buhay sa pamamagitan ng paggamit ng encapsulation. Ito ay magbibigay-daan sa iyo upang mas mahusay na subukan at mapanatili ang iyong umiiral na base ng code. .
Kung sumulat ka sa Java, kung gayon .
Bukas/sarado na prinsipyo
Ang prinsipyong ito ay madaling maalala sa pamamagitan ng pagbabasa ng sumusunod na pahayag: "Ang mga entidad ng software (mga klase, module, function, atbp.) ay dapat na bukas para sa extension, ngunit sarado para sa pagbabago." Sa pagsasagawa, nangangahulugan ito na maaari nilang payagan ang kanilang pag-uugali na baguhin nang hindi binabago ang source code.
Mahalaga ang prinsipyo kapag ang mga pagbabago sa source code ay nangangailangan ng rebisyon ng code, pagsubok sa unit, at iba pang mga pamamaraan. Ang code na sumusunod sa bukas/sarado na prinsipyo ay hindi nagbabago kapag pinalawig, kaya mas kaunti ang mga problema dito.
Narito ang isang halimbawa ng code na lumalabag sa prinsipyong ito.
Kung kailangan mong baguhin ang isang bagay sa loob nito, aabutin ito ng maraming oras, dahil ang lahat ng mga seksyon ng code na may koneksyon sa nais na fragment ay kailangang baguhin.
Sa pamamagitan ng paraan, ang pagiging bukas-sarado ay isa sa mga prinsipyo ng SOLID.
Single Responsibility Principle (SRP)
Isa pang prinsipyo mula sa SOLID set. Nakasaad dito na "may isang dahilan lamang na nagiging sanhi ng pagbabago sa klase." Isang problema lang ang nalulutas ng klase. Maaaring mayroon itong ilang mga pamamaraan, ngunit ang bawat isa sa kanila ay ginagamit lamang upang malutas ang isang karaniwang problema. Ang lahat ng mga pamamaraan at katangian ay dapat na magsilbi lamang dito.
Ang halaga ng prinsipyong ito ay pinaluwag nito ang pagkakabit sa pagitan ng indibidwal na bahagi ng software at ng code. Kung magdaragdag ka ng higit sa isang pag-andar sa isang klase, ipinakikilala nito ang isang relasyon sa pagitan ng dalawang pag-andar. Kaya, kung babaguhin mo ang isa sa mga ito, may mataas na pagkakataon na masira ang pangalawa, na konektado sa una. At nangangahulugan ito ng pagtaas ng mga ikot ng pagsubok upang matukoy ang lahat ng mga problema nang maaga.
Dependency Inversion Principle (DIP)
Sa itaas ay isang halimbawa ng code kung saan nakadepende ang AppManager sa EventLogWriter, na malapit naman na pinagsama sa AppManager. Kung kailangan mo ng ibang paraan para magpakita ng notification, push man, SMS o email, kailangan mong baguhin ang klase ng AppManager.
Ang problema ay maaaring malutas gamit ang DIP. Kaya, sa halip na AppManager, humihiling kami ng EventLogWriter, na ilalagay gamit ang framework.
Ginagawang posible ng DIP na madaling palitan ang mga indibidwal na module sa iba sa pamamagitan ng pagpapalit ng dependency module. Ginagawa nitong posible na baguhin ang isang module nang hindi naaapektuhan ang iba.
Komposisyon sa halip na mana
Mayroong dalawang pangunahing paraan upang muling gamitin ang code: mana at komposisyon, na parehong may sariling mga pakinabang at disadvantages. Kadalasan ang pangalawa ay mas gusto dahil ito ay mas nababaluktot.
Binibigyan ka ng komposisyon ng kakayahang baguhin ang pag-uugali ng isang klase sa runtime sa pamamagitan ng pagtatakda ng mga katangian nito. Kapag nagpapatupad ng mga interface, ginagamit ang polymorphism, na nagbibigay ng mas nababaluktot na pagpapatupad.
Kahit na ang Effective Java ni Joshua Bloch ay nagpapayo sa pagpili ng komposisyon kaysa sa mana.
Barbara Liskov Substitution Principle (LSP)
Isa pang prinsipyo mula sa SOLID toolkit. Ito ay nagsasaad na ang mga subtype ay dapat na maaaring palitan para sa supertype. Iyon ay, ang mga pamamaraan at pag-andar na gumagana sa isang superclass ay dapat na gumana nang walang problema sa mga subclass nito.
Ang LSP ay nauugnay sa parehong prinsipyo ng iisang responsibilidad at prinsipyo ng shared responsibility. Kung ang isang klase ay nagbibigay ng higit na functionality kaysa sa isang subclass, hindi susuportahan ng huli ang ilan sa functionality, na lumalabag sa prinsipyong ito.
Narito ang isang piraso ng code na sumasalungat sa LSP.
Ang area(Rectangle r) na pamamaraan ay kinakalkula ang lugar ng isang Rectangle. Ang programa ay mag-crash pagkatapos i-execute ang Square dahil ang Square ay hindi isang Rectangle dito. Ayon sa prinsipyo ng LSP, ang mga function na gumagamit ng mga sanggunian sa mga batayang klase ay dapat na gumamit ng mga bagay ng mga nagmula na klase nang walang karagdagang mga tagubilin.
Ang prinsipyong ito, na isang tiyak na kahulugan ng isang subtype, ay iminungkahi ni Barbara Liskov sa isang keynote ng kumperensya noong 1987 na pinamagatang "Data Abstraction and Hierarchy," kaya ang pangalan nito.
Interface Separation Principle (ISP)
Isa pang SOLID na prinsipyo. Ayon dito, hindi dapat ipatupad ang isang interface na hindi ginagamit. Ang pagsunod sa prinsipyong ito ay tumutulong sa system na manatiling flexible at angkop para sa refactoring kapag ang mga pagbabago ay ginawa sa operating logic.
Kadalasan, ang sitwasyong ito ay nangyayari kapag ang interface ay naglalaman ng ilang mga pag-andar nang sabay-sabay, at ang kliyente ay nangangailangan lamang ng isa sa mga ito.
Dahil ang pagsulat ng isang interface ay isang mahirap na gawain, ang pagbabago nito pagkatapos makumpleto ang gawain nang walang sinisira ang anumang bagay ay magiging isang hamon.
Ang bentahe ng prinsipyo ng ISP sa Java ay ang lahat ng mga pamamaraan ay dapat munang ipatupad, at pagkatapos lamang ang mga ito ay magagamit ng mga klase. Samakatuwid, ginagawang posible ng prinsipyo na bawasan ang bilang ng mga pamamaraan.
Programming para sa interface, hindi ang pagpapatupad
Ang lahat dito ay malinaw sa pangalan. Ang paglalapat ng prinsipyong ito ay humahantong sa paglikha ng flexible code na maaaring gumana sa anumang bagong pagpapatupad ng interface.
Dapat mong gamitin ang uri ng interface para sa mga variable, mga uri ng pagbabalik, o ang uri ng argumento ng pamamaraan. Ang isang halimbawa ay ang paggamit ng SuperClass sa halip na SubClass.
Hal:
Listahan ng mga numero= getNumbers();
Ngunit hindi:
Mga numero ng ArrayList = getNumbers();
Narito ang isang praktikal na pagpapatupad ng tinalakay sa itaas.
Prinsipyo ng delegasyon
Ang isang karaniwang halimbawa ay ang equals() at hashCode() na mga pamamaraan sa Java. Kapag kinakailangan upang ihambing ang dalawang bagay, ang pagkilos na ito ay itinalaga sa kaukulang klase sa halip na sa kliyente.
Ang bentahe ng prinsipyo ay walang duplikasyon ng code at medyo simple ang pagbabago ng pag-uugali. Nalalapat din ito sa pagtatalaga ng kaganapan.
Ang lahat ng mga prinsipyong ito ay nagbibigay-daan sa iyo na magsulat ng mas nababaluktot, maganda at maaasahang code na may mataas na pagkakaisa at mababang coupling. Siyempre, ang teorya ay mabuti, ngunit para sa isang developer na aktwal na magamit ang nakuha na kaalaman, kailangan ang pagsasanay. Kapag napag-aralan mo na ang mga prinsipyo ng OOP, maaaring ang susunod mong hakbang ay ang pag-aaral ng mga pattern ng disenyo upang malutas ang mga karaniwang problema sa pagbuo ng software.
Inirerekomenda ng Skillbox ang:
- Praktikal na kurso .
- Nag-apply online na kurso .
- Dalawang taong praktikal na kurso .
Pinagmulan: www.habr.com