Sa mundo ng (OOP), maraming mga alituntunin sa disenyo, pattern o prinsipyo. Lima sa mga prinsipyong ito ay karaniwang pinagsasama-sama at kilala ng akronim na SOLID. Habang ang bawat isa sa limang mga prinsipyong ito ay naglalarawan ng isang tukoy na bagay, nagsasapawan din ito tulad ng pag-aampon ng isa sa mga ito ay nagpapahiwatig o humantong sa pag-aampon ng iba pa. Sa artikulong ito maiintindihan namin ang SOLID Principle sa Java.
Kasaysayan ng SOLID Principle sa Java
Nagbigay si Robert C. Martin ng limang mga prinsipyo sa disenyo na nakatuon sa object, at ang akronim na 'S.O.L.I.D' ay ginagamit para dito. Kapag ginamit mo ang lahat ng mga prinsipyo ng S.O.L.I.D sa isang pinagsamang pamamaraan, mas madali para sa iyo na bumuo ng software na madaling mapamahalaan. Ang iba pang mga tampok ng paggamit ng S.O.L.I.D ay:
- Iniiwasan nito ang mga amoy ng code.
- Mabilis na refactor code.
- Maaaring gawin ang agpang o mabilis na pag-unlad ng software.
Kapag ginamit mo ang prinsipyo ng S.O.L.I.D sa iyong pag-coding, sinisimulan mong isulat ang code na parehong mahusay at epektibo.
Ano ang kahulugan ng S.O.L.I.D?
Ang solid ay kumakatawan sa limang prinsipyo ng java na:
- S : Prinsipyo ng solong responsibilidad
- O kaya : Open-closed na prinsipyo
- L : Liskov na prinsipyo ng pagpapalit
- Ako : Prinsipyo ng paghihiwalay ng interface
- D : Prinsipyo ng pagbabaligtad ng dependency
Sa blog na ito, tatalakayin namin ang lahat ng limang mga prinsipyo ng SOLID ng Java sa mga detalye.
mga aplikasyon ng malaking pagtatasa ng data
Single Principle Principle sa Java
Ano ang sinasabi nito?
Inilarawan ito ni Robert C. Martin na ang isang klase ay dapat magkaroon ng isa at tanging responsibilidad.
Ayon sa solong prinsipyo ng responsibilidad, dapat mayroong isang dahilan lamang kung saan kailangang palitan ang isang klase. Nangangahulugan ito na ang isang klase ay dapat magkaroon ng isang gawain na dapat gawin. Ang prinsipyong ito ay madalas na tinatawag na bilang paksa.
Ang prinsipyo ay maaaring maunawaan nang mabuti sa isang halimbawa. Isipin mayroong isang klase na gumaganap ng sumusunod na mga operasyon.
Nakakonekta sa isang database
Basahin ang ilang data mula sa mga talahanayan ng database
Panghuli, isulat ito sa isang file.
Naisip mo ba ang senaryo? Narito ang klase ay may maraming mga kadahilanan upang baguhin, at iilan sa mga ito ang pagbabago ng output ng file, bagong pag-aampon ng data base. Kapag pinag-uusapan natin ang solong responsibilidad sa prinsipyo, sasabihin namin, maraming mga dahilan para magbago ang klase mula rito, hindi ito umaangkop nang maayos sa solong prinsipyo ng responsibilidad.
Halimbawa, ang isang klase sa Automobile ay maaaring magsimula o ihinto ang sarili ngunit ang gawain sa paghuhugas nito ay kabilang sa klase ng CarWash. Sa isa pang halimbawa, ang isang klase sa Book ay may mga katangian upang maiimbak ang sarili nitong pangalan at teksto. Ngunit ang gawain ng pag-print ng libro ay dapat na kabilang sa klase ng Book Printer. Ang klase ng Book Printer ay maaaring mag-print sa console o ibang medium ngunit ang mga nasabing dependency ay inalis mula sa klase ng Book
Bakit kinakailangan ang Prinsipyong ito?
Kapag sinusunod ang Prinsipyo ng Single na Responsibilidad, mas madali ang pagsubok. Sa isang solong responsibilidad, ang klase ay magkakaroon ng mas kaunting mga kaso sa pagsubok. Ang mas kaunting pag-andar ay nangangahulugang mas kaunting mga pagtitiwala sa iba pang mga klase. Humahantong ito sa mas mahusay na samahan ng code dahil mas madaling maghanap ang mga maliit at maayos na klase.
Isang halimbawa upang linawin ang alituntuning ito:
Ipagpalagay na tatanungin ka upang magpatupad ng isang serbisyo ng UserSetting kung saan maaaring baguhin ng gumagamit ang mga setting ngunit bago ito kailangang kumpirmahin ang gumagamit. Ang isang paraan upang maipatupad ito ay:
public class UserSettingService {public void changeEmail (User user) {if (checkAccess (user)) {// Grant options to change}} public boolean checkAccess (User user) {// I-verify kung ang gumagamit ay wasto. }}Ang lahat ay mukhang mabuti hanggang sa nais mong muling magamit ang checkAccess code sa ibang lugar O nais mong gumawa ng mga pagbabago sa paraang ginagawa sa checkAccess. Sa lahat ng 2 mga kaso tatapusin mo ang pagbabago ng parehong klase at sa unang kaso kakailanganin mong gamitin ang UserSettingService upang suriin din ang pag-access.
Ang isang paraan upang maitama ito ay upang mabulok ang UserSettingService sa UserSettingService at SecurityService. At ilipat ang checkAccess code sa SecurityService.
public class UserSettingService {public void changeEmail (User user) {if (SecurityService.checkAccess (user)) {// Grant pagpipilian upang baguhin}}} public class SecurityService {public static boolean checkAccess (User user) {// suriin ang access. }}Buksan ang Saradong Prinsipyo sa Java
Inilarawan ito ni Robert C. Martin bilang ang mga bahagi ng software ay dapat bukas para sa extension, ngunit sarado para sa pagbabago.
Upang maging tumpak, ayon sa prinsipyong ito, ang isang klase ay dapat na nakasulat sa paraang ginagampanan nito ang trabaho nang walang kapintasan nang walang palagay na ang mga tao sa hinaharap ay darating at babaguhin lamang ito. Samakatuwid, ang klase ay dapat manatiling sarado para sa pagbabago, ngunit dapat itong magkaroon ng pagpipilian upang mapalawak. Ang mga paraan ng pagpapalawak ng klase ay kinabibilangan ng:
Nagmamana sa klase
Pag-o-overwrite ng mga kinakailangang pag-uugali mula sa klase
Pagpapalawak ng ilang mga pag-uugali ng klase
Ang isang mahusay na halimbawa ng bukas-na-prinsipyo na prinsipyo ay maaaring maunawaan sa tulong ng mga browser. Naaalala mo ba ang pag-install ng mga extension sa iyong chrome browser?
Pangunahing pagpapaandar ng chrome browser ay ang pag-surf sa iba't ibang mga site. Nais mo bang suriin ang balarila kapag nagsusulat ka ng isang email gamit ang chrome browser? Kung oo, maaari mo lamang gamitin ang Grammarly extension, nagbibigay sa iyo ng tseke sa gramatika sa nilalaman.
Ang mekanismong ito kung saan nagdaragdag ka ng mga bagay para sa pagtaas ng pag-andar ng browser ay isang extension. Samakatuwid, ang browser ay isang perpektong halimbawa ng pag-andar na bukas para sa extension ngunit sarado para sa pagbabago. Sa mga simpleng salita, maaari mong mapahusay ang pag-andar sa pamamagitan ng pagdaragdag / pag-install ng mga plugin sa iyong browser, ngunit hindi makakagawa ng anumang bago.
Bakit kinakailangan ang prinsipyong ito?
Mahalaga ang OCP dahil ang mga klase ay maaaring dumating sa amin sa pamamagitan ng mga third-party na aklatan. Dapat naming mapalawak ang mga klase na walang pag-aalala kung ang mga batayang klase ay maaaring suportahan ang aming mga extension. Ngunit ang mana ay maaaring humantong sa mga subclass na nakasalalay sa pagpapatupad ng base class. Upang maiwasan ito, inirerekumenda ang paggamit ng mga interface. Ang karagdagang abstraction na ito ay humahantong sa maluwag na pagkabit.
Hinahayaan nating sabihin na kailangan nating kalkulahin ang mga lugar ng iba't ibang mga hugis. Nagsisimula kami sa paglikha ng isang klase para sa aming unang hugis ng Parihabana may 2 haba ng mga katangian& lapad.
pampublikong klase Rectangle {publiko na doble ang haba ng publiko na doble ang lapad}Susunod na lumikha kami ng isang klase upang makalkula ang lugar ng Rectangle na itona may isang paraan kalkulahinRectangleAreana kumukuha ng Rectanglebilang isang input parameter at kinakalkula ang lugar nito.
pampublikong klase AreaCalculator {pampubliko na doble kalkulahinRectangleArea (Parihaba parihaba) {bumalik rektanggulo.length * rektanggulo.width}}Sa ngayon napakahusay. Ngayon sabihin nating nakukuha natin ang aming pangalawang hugis ng bilog. Kaya agad kaming lumilikha ng isang bagong klase ng Circlena may isang radius ng katangian.
pampublikong klase ng Circle {public double radius}Pagkatapos ay binago namin ang Areacalculatorklase upang magdagdag ng mga kalkulasyon ng bilog sa pamamagitan ng isang bagong pamamaraan kalkulahin angCircleaArea ()
publikong klase AreaCalculator {publiko dobleng pagkalkulaRectangleArea (Parihaba parihaba) {bumalik rektanggulo.length * rektanggulo.width} pampubliko na dobleng pagkalkulaCircleArea (Circle circle) {return (22/7) * circle.radius * circle.radius}}Gayunpaman, tandaan na may mga pagkukulang sa paraan ng pagdidisenyo namin ng aming solusyon sa itaas.
Hinahayaan nating sabihin na mayroon tayong bagong hugis na pentagon. Sa kasong iyon, tatapusin namin ulit ang pagbabago ng klase ng AreaCalculator. Habang lumalaki ang mga uri ng mga hugis ay naging mas magulo ito dahil ang AreaCalculator ay patuloy na nagbabago at ang sinumang mga mamimili ng klase na ito ay mananatili sa pag-update ng kanilang mga aklatan na naglalaman ng AreaCalculator. Bilang isang resulta, ang klase ng AreaCalculator ay hindi bibigyan ng baselined (finalized) na may katiyakan sa tuwing darating ang isang bagong hugis mababago ito. Kaya, ang disenyo na ito ay hindi sarado para sa pagbabago.
Kailangang panatilihin ng AreaCalculator na idagdag ang kanilang lohika sa pagkalkula sa mga mas bagong pamamaraan. Hindi namin talaga pinalawak ang saklaw ng mga hugis sa halip gumagawa lamang kami ng solusyon sa piraso ng pagkain (bit-by-bit) para sa bawat hugis na naidagdag.
Pagbabago ng disenyo sa itaas upang sumunod sa binuksan / saradong prinsipyo:
Tingnan natin ngayon ang isang mas matikas na disenyo na malulutas ang mga bahid sa disenyo sa itaas sa pamamagitan ng pagsunod sa Open / Closed Principle. Una naming gagawin ang disenyo na napapalawak. Para sa mga ito kailangan muna naming tukuyin ang isang pangunahing uri ng Hugis at ipatupad ang Circle & Rectangle na interface ng Hugis.
pampubliko na interface Hugis {public double calculArea ()} pampubliko na klase na Parihabang ipinapatupad Hugis {doble haba doble na lapad ng publiko dobleng calculArea () {haba ng pagbalik * lapad}} pampubliko na klase Circle nagpapatupad Hugis {pampublikong dobleng radius publiko dobleng calculArea () {bumalik (22 / 7) * radius * radius}}Mayroong isang base interface na Hugis. Ipatupad na ngayon ng lahat ng mga hugis ang base interface na Hugis. Ang interface ng hugis ay may isang abstract na paraan ng pagkalkula ngArea (). Ang parehong bilog at rektanggulo ay nagbibigay ng kanilang sariling labis na pagpapatupad ng pamamaraang calculArea () gamit ang kanilang sariling mga katangian.
Nagdala kami ng isang antas ng pagiging malawak dahil ang mga hugis ay isang halimbawa na ngayon ng mga interface ng Hugis. Pinapayagan kaming gumamit ng Hugis sa halip na mga indibidwal na klase
Ang huling punto sa itaas ay binanggit ang mamimili ng mga hugis na ito. Sa aming kaso, ang mamimili ay ang magiging klase ng AreaCalculator na magiging ganito ngayon.
pampublikong klase AreaCalculator {pampubliko na doble ang pagkalkulaShapeArea (Hugis ng Hugis) {return form.calculateArea ()}}Ang AreaCalculator na itoganap na inaalis ng klase ang aming mga bahid sa disenyo na nabanggit sa itaas at nagbibigay ng isang malinis na solusyon na sumusunod sa Open-Closed Principle. Magpatuloy tayo sa iba pang mga SOLID Principle sa Java
Liskov Substitution Principle sa Java
Inilarawan ito ni Robert C. Martin bilang mga nagmula sa mga uri ay dapat na ganap na kapalit ng kanilang mga pangunahing uri.
Ipinapalagay ng prinsipyo ng pagpapalit ng Liskov na ang q (x) ay isang pag-aari, napatunayan tungkol sa mga entity ng x na kabilang sa uri ng T. Ngayon, ayon sa prinsipyong ito, ang q (y) ay dapat na mapatunayan ngayon para sa mga bagay na kabilang sa uri ng S, at ang S ay talagang isang sub uri ng T. Naguguluhan ka ba ngayon at hindi mo alam kung ano ang talagang ibig sabihin ng prinsipyo ng pagpapalit ng Liskov? Ang kahulugan nito ay maaaring medyo kumplikado, ngunit sa katunayan, ito ay medyo madali. Ang tanging bagay ay ang bawat subclass o nagmula sa klase ay dapat na pamalit para sa kanilang magulang o base class.
Maaari mong sabihin na ito ay isang natatanging prinsipyo na nakatuon sa object. Ang prinsipyo ay maaaring karagdagang gawing simple ng isang uri ng bata ng isang partikular na uri ng magulang nang hindi gumagawa ng anumang komplikasyon o pamumulaklak ng mga bagay ay dapat magkaroon ng kakayahang tumayo para sa magulang na iyon. Ang prinsipyong ito ay malapit na nauugnay sa prinsipyo ng Liskov Substitution.
Bakit kinakailangan ang prinsipyong ito?
Iniiwasan nito ang maling paggamit ng mana. Tinutulungan tayo nitong umayon sa relasyon na 'is-a'. Maaari din nating sabihin na ang mga subclass ay dapat na matupad ang isang kontrata na tinukoy ng batayang klase. Sa puntong ito, nauugnay ito saDisenyo ng Kontratana unang inilarawan ni Bertrand Meyer. Halimbawa, nakakaakit na sabihin na ang isang bilog ay isang uri ng ellipse ngunit ang mga bilog ay walang dalawang foci o major / minor axes.
Ang LSP ay sikat na ipinaliwanag gamit ang halimbawa ng parisukat at parihaba. kung ipinapalagay natin ang isang relasyon sa ISA sa pagitan ng Square at Rectangle. Sa gayon, tinatawag naming 'Square is a Rectangle.' Ang code sa ibaba ay kumakatawan sa relasyon.
pampublikong klase Parihaba {pribadong int haba ng pribadong int lapad ng publiko int getLength () {haba ng pagbabalik} pampublikong walang bisa na setLength (int haba) {this.length = haba} publiko int getBreadth () {ibalik ang lapad} publiko walang bisa setBreadth (int lapad) { this.breadth = breadth} public int getArea () {ibalik ito.length * this.breadth}}Nasa ibaba ang code para sa Square. Tandaan na pinalawak ng Square ang Parihaba.
kung paano gamitin ang substring sa java
pampublikong klase Ang parisukat ay umaabot sa Rectangle {public void setBreadth (int breadth) {super.setBreadth (breadth) super.setLength (breadth)} public void setLength (int haba) {super.setLength (haba) super.setBreadth (haba)}}Sa kasong ito, sinubukan naming magtaguyod ng isang ugnayan ng ISA sa pagitan ng Square at Rectangle tulad ng pagtawag sa 'Square is a Rectangle' sa ibaba na code ay magsisimulang kumilos nang hindi inaasahan kung ang isang halimbawa ng Square ay naipasa. Ang isang error sa assertion ay itatapon sa kaso ng pag-check para sa 'Area' at pag-check para sa 'Breadth,' bagaman matatapos ang programa habang ang error ng assertion ay itinapon dahil sa pagkabigo ng tseke sa Area.
pampublikong klase LSPDemo {public void calculArea (Rectangle r) {r.setBreadth (2) r.setLength (3) assert r.getArea () == 6: printError ('area', r) igiit ang r.getLength () == 3: printError ('haba', r) igiit ang r.getBreadth () == 2: printError ('lawak', r)} pribadong String printError (String errorIdentifer, Rectangle r) {return 'Hindi inaasahang halaga ng' + errorIdentifer + ' halimbawa ng '+ r.getClass (). getName ()} public static void main (String [] args) {LSPDemo lsp = new LSPDemo () // Ang isang halimbawa ng Rectangle ay naipasa lsp.calculateArea (bagong Rectangle ()) // Isang halimbawa ng Square ang naipasa lsp.calculateArea (bagong Square ())}} Ipinapakita ng klase ang Liskov Substitution Principle (LSP) Alinsunod sa prinsipyo, ang mga pagpapaandar na gumagamit ng mga sanggunian sa mga pangunahing klase ay dapat na maaaring gumamit ng mga bagay na nagmula sa klase nang hindi alam ito.
Kaya, sa halimbawang ipinakita sa ibaba, ang function na calculateArea na gumagamit ng sanggunian ng 'Rectangle' ay dapat na magamit ang mga bagay ng nagmula sa klase tulad ng Square at matupad ang hinihiling na ipinahiwatig ng kahulugan ng Rectangle. Dapat tandaan ng isa na alinsunod sa kahulugan ng Rectangle, dapat sundin ng totoo ang sumusunod na binigyan ng data sa ibaba:
- Ang haba ay dapat palaging katumbas ng haba na ipinasa bilang input sa pamamaraan, itinakda ang Haba
- Ang lapad ay dapat palaging pantay sa lapad na ipinasa bilang input sa pamamaraan, setBreadth
- Ang lugar ay dapat palaging katumbas ng produkto ng haba at lawak
Kung sakali, susubukan naming maitaguyod ang ugnayan ng ISA sa pagitan ng Square at Rectangle na tinatawag naming 'Square is a Rectangle', sa itaas ng code ay magsisimulang kumilos nang hindi inaasahan kung ang isang halimbawa ng Square ay naipasa Ang error sa pag-asser ay itatapon sa kaso ng tseke para sa lugar at suriin para sa lawak, bagaman ang programa ay magwawakas ng ang error ng assertion ay itinapon dahil sa kabiguan ng Area check.
Ang klase ng Square ay hindi nangangailangan ng mga pamamaraan tulad ng setBreadth o setLength. Kailangang malaman ng klase ng LSPDemo ang mga detalye ng nagmula sa mga klase ng Rectangle (tulad ng Square) upang mag-code nang naaangkop upang maiwasan ang pagkahagis ng error. Ang pagbabago sa mayroon nang code ay sumisira sa bukas na prinsipyong bukas-sarado.
Prinsipyo ng Paghihiwalay ng Interface
Inilarawan ito ni Robert C. Martin dahil ang mga kliyente ay hindi dapat pinilit na magpatupad ng hindi kinakailangang mga pamamaraan na hindi nila gagamitin.
Ayon kayPrinsipyo ng paghihiwalay ng interfaceisang kliyente, anuman ang hindi dapat sapilitang ipatupad ang isang interface na hindi nito ginagamit o ang kliyente ay hindi kailanman dapat mapilitang umasa sa anumang pamamaraan, na hindi nila ginagamit. Kaya karaniwang, ang mga prinsipyo ng paghihiwalay ng interface na mas gusto mo ang mga interface, na kung saan ay maliit ngunit tukoy sa client sa halip na monolithic at mas malaking interface. Sa madaling salita, masama para sa iyo na pilitin ang kliyente na umasa sa isang tiyak na bagay, na hindi nila kailangan.
Halimbawa, ang isang solong interface ng pag-log para sa pagsulat at pagbabasa ng mga log ay kapaki-pakinabang para sa isang database ngunit hindi para sa isang console. Ang pagbasa ng mga tala ay walang katuturan para sa isang console logger. Ang pagpapatuloy sa artikulong SOLID sa Java na artikulong ito.
Bakit kinakailangan ang prinsipyong ito?
Sabihin natin na mayroong isang interface ng Restaurant na naglalaman ng mga pamamaraan para sa pagtanggap ng mga order mula sa mga online na customer, mga customer sa pag-dial-in o telepono at mga customer sa paglalakad. Naglalaman din ito ng mga pamamaraan para sa paghawak ng mga pagbabayad sa online (para sa mga online na customer) at mga pagbabayad na pansamantala (para sa mga walk-in customer pati na rin mga customer sa telepono kapag ang kanilang order ay naihatid sa bahay).
Ngayon ay lumikha tayo ng isang Java Interface para sa Restaurant at pangalanan ito bilang RestaurantInterface.java.
pampublikong interface RestaurantInterface {public void acceptOnlineOrder () public void takeTelephoneOrder () public void payOnline () public void walkInCustomerOrder () public void payInPerson ()}Mayroong 5 mga pamamaraan na tinukoy sa RestaurantInterface na kung saan ay para sa pagtanggap ng online order, pagkuha ng order sa telephonic, pagtanggap ng mga order mula sa isang walk-in customer, pagtanggap ng online na pagbabayad at pagtanggap ng bayad nang personal.
Magsimula tayo sa pamamagitan ng pagpapatupad ng RestaurantInterface para sa mga online na customer bilang OnlineClientImpl.java
pampublikong klase OnlineClientImpl nagpapatupad ng RestaurantInterface {public void acceptOnlineOrder () {// lohika para sa paglalagay ng online order} publikong walang bisa takeTelephoneOrder () {// Hindi Naaangkop para sa Online Order na magtapon ng bagong UnsupportedOperationException ()} pampublikong walang bisa na payOnline () {// lohika para sa pagbabayad online} public void walkInCustomerOrder () {// Not Applicable for Online Order magtapon ng bagong UnsupportedOperationException ()} public void payInPerson () {// Not Applicable for Online Order magtapon ng bagong UnsupportedOperationException ()}}Dahil ang code sa itaas (OnlineClientImpl.java) ay para sa mga online na order, itapon ang UnsupportedOperationException.
Ang mga kliyente sa online, telephonic at walk-in ay gumagamit ng pagpapatupad ng RestaurantInterface na tukoy sa bawat isa sa kanila.
Ang mga klase sa pagpapatupad para sa Telephonic client at Walk-in client ay magkakaroon ng mga hindi suportadong pamamaraan.
Dahil ang 5 pamamaraan ay bahagi ng RestaurantInterface, ang mga klase sa pagpapatupad ay kailangang ipatupad ang lahat ng 5 sa kanila.
Ang mga pamamaraan na itinapon ng bawat isa sa mga klase sa pagpapatupad ng Hindi sinusuportahang OpsyonException. Tulad ng malinaw mong nakikita - ang pagpapatupad ng lahat ng mga pamamaraan ay hindi mabisa.
Ang anumang pagbabago sa alinman sa mga pamamaraan ng RestaurantInterface ay ikakalat sa lahat ng mga klase sa pagpapatupad. Ang pagpapanatili ng code pagkatapos ay nagsisimulang maging talagang masalimuot at pagbabalik ng mga epekto ng mga pagbabago ay patuloy na tataas.
Sinira ng RestaurantInterface.java ang Prinsipyo ng Single Responsibilidad dahil ang lohika para sa mga pagbabayad pati na rin para sa pagkakalagay ng order ay pinagsama-sama sa isang solong interface.
Upang mapagtagumpayan ang mga nabanggit na problema, inilalapat namin ang Prinsipyo ng Paghihiwalay ng Interface upang mapabago ang disenyo sa itaas.
Paghiwalayin ang mga pag-andar sa pagbabayad at pag-order ng pagkakalagay sa dalawang magkakahiwalay na mga interface ng lean, PaymentInterface.java at OrderInterface.java.
Ang bawat kliyente ay gumagamit ng isang pagpapatupad bawat isa sa PaymentInterface at OrderInterface. Halimbawa - OnlineClient.java ay gumagamit ng OnlinePaymentImpl at OnlineOrderImpl at iba pa.
Ang Prinsipyo ng Single Responsibilidad ay nakakabit na ngayon bilang interface ng Pagbabayad (PaymentInterface.java) at interface ng Pag-order (OrderInterface).
Ang pagbabago sa anumang isa sa mga order ng order o pagbabayad ay hindi nakakaapekto sa iba pa. Malaya na sila ngayon. Hindi na kakailanganin na gumawa ng anumang pagpapatupad ng dummy o magtapon ng isang UnsupportedOperationException dahil ang bawat interface ay may mga pamamaraan lamang na palaging gagamitin nito.
Matapos ilapat ang ISP
pag-convert ng binary sa decimal sa java
Prinsipyo ng Pagbabaliktad sa Dependensya
Inilalarawan ito ni Robert C. Martin dahil nakasalalay ito sa mga abstraksiyon hindi sa mga konkreto. Ayon dito, ang module na may mataas na antas ay hindi dapat umaasa sa anumang modyul na mababang antas. Halimbawa
Pumunta ka sa isang lokal na tindahan upang bumili ng anumang bagay, at nagpasya kang bayaran ito sa pamamagitan ng paggamit ng iyong debit card. Kaya, kapag binigay mo ang iyong card sa klerk para sa pagbabayad, ang klerk ay hindi nag-abala upang suriin kung anong uri ng kard ang iyong ibinigay.
Kahit na nagbigay ka ng isang Visa card, hindi siya maglalagay ng isang Visa machine para sa pag-swipe ng iyong card. Ang uri ng credit card o debit card na mayroon ka para sa pagbabayad ay hindi mahalaga na swipe lang nila ito. Kaya, sa halimbawang ito, maaari mong makita na kapwa ikaw at ang klerk ay umaasa sa abstraction ng credit card at hindi ka nag-aalala tungkol sa mga detalye ng card. Ito ang kung ano ang isang prinsipyo ng pagbabaligtad ng dependency.
Bakit kinakailangan ang prinsipyong ito?
Pinapayagan nito ang isang programmer na alisin ang mga hardcoded dependency upang ang application ay maging maluwag na kaisa at mapalawak.
pampublikong klase Mag-aaral {pribadong address ng address publiko ng Mag-aaral () {address = bagong Address ()}}Sa halimbawa sa itaas, ang klase ng Mag-aaral ay nangangailangan ng isang object ng Address at responsable ito sa pagsisimula at paggamit ng Address ng object. Kung ang klase sa Address ay binago sa hinaharap pagkatapos ay kailangan ding gumawa ng mga pagbabago sa klase ng Mag-aaral din. Ginagawa nitong mahigpit ang pagkabit sa pagitan ng mga bagay ng Mag-aaral at Address. Maaari naming malutas ang problemang ito gamit ang pattern ng disenyo ng pagbaluktot ng dependency. ibig sabihin, ang object ng address ay ipatutupad nang nakapag-iisa at ibibigay sa Mag-aaral kapag ang Mag-aaral ay pinag-uusapan sa pamamagitan ng paggamit ng pagkakabaligtad na nakabatay sa konstruktor o batay sa setter.
Sa pamamagitan nito, natapos namin ang SOLID Principle na ito sa Java.
Suriin ang ni Edureka, isang pinagkakatiwalaang kumpanya sa pag-aaral sa online na may isang network na higit sa 250,000 nasiyahan na mga nag-aaral na kumalat sa buong mundo. Ang kurso sa pagsasanay at sertipikasyon ng Java J2EE at SOA ng Edureka ay idinisenyo para sa mga mag-aaral at propesyonal na nais na maging isang Java Developer. Ang kurso ay dinisenyo upang bigyan ka ng isang panimula sa pag-program ng Java at sanayin ka para sa parehong core at advanced na mga konsepto ng Java kasama ang iba't ibang mga balangkas ng Java tulad ng Hibernate & Spring.
May tanong ba sa amin? Mangyaring banggitin ito sa seksyon ng mga komento ng blog na 'SOLID Mga Prinsipyo sa Java' at babalikan ka namin sa lalong madaling panahon.