Mga Panuntunan sa Pag-coding: Mula sa Paglikha ng System hanggang sa Paggawa sa Mga Bagay

Magandang araw, lahat! Ngayon gusto naming makipag-usap sa iyo tungkol sa pagsulat ng magandang code. Siyempre, hindi lahat ay gustong ngumunguya kaagad sa mga aklat tulad ng Clean Code, dahil naglalaman ang mga ito ng napakaraming impormasyon ngunit hindi gaanong malinaw sa simula. At sa oras na matapos mo ang pagbabasa, maaari mong patayin ang lahat ng iyong pagnanais na mag-code. Isinasaalang-alang ang lahat ng iyon, ngayon gusto kong bigyan ka ng isang maliit na gabay (isang maliit na hanay ng mga rekomendasyon) para sa pagsusulat ng mas mahusay na code. Sa artikulong ito, talakayin natin ang mga pangunahing panuntunan at konsepto na nauugnay sa paggawa ng system at pagtatrabaho sa mga interface, klase, at mga bagay. Ang pagbabasa ng artikulong ito ay hindi kukuha ng maraming oras at, umaasa ako, ay hindi magsasawa sa iyo. Gagawin ko ang aking paraan mula sa itaas hanggang sa ibaba, ibig sabihin, mula sa pangkalahatang istraktura ng isang application hanggang sa mas makitid na mga detalye nito.

Mga sistema

Ang mga sumusunod ay karaniwang kanais-nais na mga katangian ng isang sistema:

• Minimal na pagiging kumplikado. Ang mga sobrang kumplikadong proyekto ay dapat iwasan. Ang pinakamahalagang bagay ay ang pagiging simple at kalinawan (mas simple = mas mahusay).
• Dali ng pagpapanatili. Kapag gumagawa ng isang application, dapat mong tandaan na ito ay kailangang mapanatili (kahit na ikaw mismo ay hindi mananagot sa pagpapanatili nito). Nangangahulugan ito na ang code ay dapat na malinaw at malinaw.
• Maluwag na pagkabit. Nangangahulugan ito na pinapaliit namin ang bilang ng mga dependency sa pagitan ng iba't ibang bahagi ng programa (pagmaximize ng aming pagsunod sa mga prinsipyo ng OOP).
• Reusability. Idinisenyo namin ang aming system na may kakayahang muling gamitin ang mga bahagi sa iba pang mga application.
• Portability. Dapat ay madaling iakma ang isang sistema sa ibang kapaligiran.
• Uniform style. Idinisenyo namin ang aming system gamit ang isang pare-parehong istilo sa iba't ibang bahagi nito.
• Extensibility (scalability). Mapapahusay natin ang system nang hindi nilalabag ang pangunahing istraktura nito (hindi dapat makaapekto sa lahat ng iba pa ang pagdaragdag o pagbabago ng isang bahagi).

Ito ay halos imposible na bumuo ng isang application na hindi nangangailangan ng mga pagbabago o bagong pag-andar. Patuloy naming kakailanganing magdagdag ng mga bagong bahagi upang matulungan ang aming brainchild na makasabay sa mga panahon. Dito pumapasok ang scalability. Ang scalability ay mahalagang pagpapalawak ng application, pagdaragdag ng bagong functionality, at pagtatrabaho sa mas maraming mapagkukunan (o, sa madaling salita, na may mas malaking load). Sa madaling salita, upang gawing mas madaling magdagdag ng bagong lohika, nananatili kami sa ilang mga panuntunan, tulad ng pagbabawas ng pagkakabit ng system sa pamamagitan ng pagtaas ng modularity.

Pinagmulan ng Larawan

Mga yugto ng pagdidisenyo ng isang sistema

1. Sistema ng software. Idisenyo ang application sa pangkalahatan.
2. Dibisyon sa mga subsystem/package. Tukuyin ang lohikal na natatanging mga bahagi at tukuyin ang mga panuntunan para sa pakikipag-ugnayan sa pagitan ng mga ito.
3. Dibisyon ng mga subsystem sa mga klase. Hatiin ang mga bahagi ng system sa mga partikular na klase at interface, at tukuyin ang pakikipag-ugnayan sa pagitan ng mga ito.
4. Dibisyon ng mga klase sa mga pamamaraan. Gumawa ng kumpletong kahulugan ng mga kinakailangang pamamaraan para sa isang klase, batay sa itinalagang responsibilidad nito.
5. Disenyo ng pamamaraan. Lumikha ng isang detalyadong kahulugan ng pag-andar ng mga indibidwal na pamamaraan.

Karaniwang pinangangasiwaan ng mga ordinaryong developer ang disenyong ito, habang pinangangasiwaan ng arkitekto ng application ang mga puntong inilarawan sa itaas.

Pangkalahatang mga prinsipyo at konsepto ng disenyo ng system

Tamad na pagsisimula. Sa programming idiom na ito, ang application ay hindi nag-aaksaya ng oras sa paglikha ng isang bagay hanggang sa ito ay aktwal na ginagamit. Pinapabilis nito ang proseso ng pagsisimula at binabawasan ang pagkarga sa kolektor ng basura. Iyon ay sinabi, hindi mo dapat gawin ito nang masyadong malayo, dahil maaaring lumabag iyan sa prinsipyo ng modularity. Marahil ito ay nagkakahalaga ng paglipat ng lahat ng mga pagkakataon ng konstruksiyon sa ilang partikular na bahagi, halimbawa, ang pangunahing pamamaraan o sa isang klase ng pabrika . Ang isang katangian ng magandang code ay ang kawalan ng paulit-ulit, boilerplate code. Bilang isang tuntunin, ang naturang code ay inilalagay sa isang hiwalay na klase upang ito ay matawagan kapag kinakailangan.

AOP

Gusto ko ring tandaan ang aspect-oriented na programming. Ang paradigma ng programming na ito ay tungkol sa pagpapakilala ng transparent na lohika. Iyon ay, ang paulit-ulit na code ay inilalagay sa mga klase (mga aspeto) at tinatawag kapag nasiyahan ang ilang mga kundisyon. Halimbawa, kapag tumatawag sa isang pamamaraan na may partikular na pangalan o nag-a-access sa isang variable ng isang partikular na uri. Minsan ang mga aspeto ay maaaring nakalilito, dahil hindi agad malinaw kung saan ang code ay tinawag, ngunit ito ay napaka-kapaki-pakinabang na pag-andar. Lalo na kapag nag-cache o nagla-log. Idinagdag namin ang pagpapaandar na ito nang hindi nagdaragdag ng karagdagang lohika sa mga ordinaryong klase. Apat na panuntunan ni Kent Beck para sa isang simpleng arkitektura:

1. Pagpapahayag - Ang layunin ng isang klase ay dapat na malinaw na ipinahayag. Ito ay nakakamit sa pamamagitan ng wastong pagpapangalan, maliit na sukat, at pagsunod sa prinsipyo ng solong responsibilidad (na isasaalang-alang namin nang mas detalyado sa ibaba).
2. Pinakamababang bilang ng mga klase at pamamaraan — Sa iyong pagnanais na gawin ang mga klase bilang maliit at makitid na nakatutok hangga't maaari, maaari kang pumunta ng masyadong malayo (na nagreresulta sa anti-pattern ng operasyon ng shotgun). Ang prinsipyong ito ay nangangailangan ng pagpapanatiling compact ng system at hindi masyadong malayo, na lumilikha ng isang hiwalay na klase para sa bawat posibleng aksyon.
3. Walang duplikasyon — Ang duplicate na code, na lumilikha ng kalituhan at isang indikasyon ng suboptimal na disenyo ng system, ay kinukuha at inilipat sa isang hiwalay na lokasyon.
4. Pinapatakbo ang lahat ng pagsubok — Ang isang system na pumasa sa lahat ng pagsubok ay mapapamahalaan. Ang anumang pagbabago ay maaaring maging sanhi ng isang pagsubok na mabigo, na nagpapakita sa amin na ang aming pagbabago sa panloob na lohika ng isang pamamaraan ay nagbago din ng pag-uugali ng system sa mga hindi inaasahang paraan.

SOLID

Kapag nagdidisenyo ng isang sistema, ang kilalang mga prinsipyo ng SOLID ay nagkakahalaga ng pagsasaalang-alang:

S (iisang responsibilidad), O (open-closed), L (Liskov substitution), I (interface segregation), D (dependency inversion).

Hindi namin tatalakayin ang bawat indibidwal na prinsipyo. Iyon ay medyo lampas sa saklaw ng artikulong ito, ngunit maaari kang magbasa ng higit pa dito .

Interface

Marahil ang isa sa pinakamahalagang hakbang sa paglikha ng isang mahusay na disenyo ng klase ay ang paglikha ng isang mahusay na dinisenyo na interface na kumakatawan sa isang mahusay na abstraction, pagtatago ng mga detalye ng pagpapatupad ng klase at sabay-sabay na pagpapakita ng isang pangkat ng mga pamamaraan na malinaw na pare-pareho sa isa't isa. Tingnan natin ang isa sa mga SOLID na prinsipyo — paghiwalay ng interface: ang mga kliyente (mga klase) ay hindi dapat magpatupad ng mga hindi kinakailangang pamamaraan na hindi nila gagamitin. Sa madaling salita, kung pinag-uusapan natin ang paglikha ng isang interface na may pinakamababang bilang ng mga pamamaraan na naglalayong gawin ang tanging trabaho ng interface (na sa palagay ko ay halos kapareho sa isang prinsipyo ng responsibilidad), mas mahusay na lumikha ng isang pares ng mga mas maliit sa halip. ng isang namamaga na interface. Sa kabutihang palad, ang isang klase ay maaaring magpatupad ng higit sa isang interface. Tandaang pangalanan nang maayos ang iyong mga interface: dapat ipakita ng pangalan ang nakatalagang gawain nang tumpak hangga't maaari. At, siyempre, mas maikli ito, mas kaunting pagkalito ang idudulot nito. Ang mga komento sa dokumentasyon ay karaniwang nakasulat sa antas ng interface. Ang mga komentong ito ay nagbibigay ng mga detalye tungkol sa kung ano ang dapat gawin ng bawat pamamaraan, anong mga argumento ang kinakailangan, at kung ano ang ibabalik nito.

Klase

Pinagmulan ng Larawan

Tingnan natin kung paano isinasaayos ang mga klase sa loob. O sa halip, ilang mga pananaw at tuntunin na dapat sundin kapag nagsusulat ng mga klase. Bilang panuntunan, dapat magsimula ang isang klase sa isang listahan ng mga variable sa isang partikular na pagkakasunud-sunod:

1. pampublikong static constants;
2. pribadong static constants;
3. mga variable ng pribadong instance.

Susunod na dumating ang iba't ibang mga konstruktor, sa pagkakasunud-sunod mula sa mga may kaunting mga argumento hanggang sa mga may pinakamaraming. Sinusundan sila ng mga pamamaraan mula sa pinaka-publiko hanggang sa pinakapribado. Sa pangkalahatan, ang mga pribadong pamamaraan na nagtatago sa pagpapatupad ng ilang functionality na gusto naming paghigpitan ay nasa pinakailalim.

Laki ng klase

Ngayon gusto kong pag-usapan ang laki ng mga klase. Alalahanin natin ang isa sa mga SOLID na prinsipyo — ang nag-iisang prinsipyo ng responsibilidad. Ito ay nagsasaad na ang bawat bagay ay may isang layunin lamang (responsibilidad), at ang lohika ng lahat ng mga pamamaraan nito ay naglalayong maisakatuparan ito. Sinasabi nito sa atin na iwasan ang malalaking klase (na talagang kontra-pattern ng object ng Diyos), at kung marami tayong mga pamamaraan na may iba't ibang uri ng lohika na nakasiksik sa isang klase, kailangan nating pag-isipan ang paghiwa-hiwalayin ito sa isang pares ng mga lohikal na bahagi (mga klase). Ito naman, ay magpapataas sa pagiging madaling mabasa ng code, dahil hindi magtatagal upang maunawaan ang layunin ng bawat pamamaraan kung alam natin ang tinatayang layunin ng anumang partikular na klase. Gayundin, pagmasdan ang pangalan ng klase, na dapat ipakita ang lohika na nilalaman nito. Halimbawa, kung mayroon kaming klase na may 20+ salita sa pangalan nito, kailangan nating isipin ang tungkol sa refactoring. Ang anumang klase na may paggalang sa sarili ay hindi dapat magkaroon ng ganoon karaming mga panloob na variable. Sa katunayan, gumagana ang bawat pamamaraan sa isa o ilan sa kanila, na nagdudulot ng maraming pagkakaisa sa loob ng klase (na eksakto kung ano ang nararapat, dahil ang klase ay dapat na isang pinag-isang kabuuan). Bilang resulta, ang pagtaas ng pagkakaisa ng isang klase ay humahantong sa isang pagbawas sa laki ng klase, at, siyempre, ang bilang ng mga klase ay tumataas. Nakakainis ito para sa ilang tao, dahil kailangan mong bumasang mabuti sa mga file ng klase nang higit pa upang makita kung paano gumagana ang isang partikular na malaking gawain. Higit sa lahat, ang bawat klase ay isang maliit na module na dapat ay minimal na nauugnay sa iba. Binabawasan ng paghihiwalay na ito ang bilang ng mga pagbabagong kailangan nating gawin kapag nagdaragdag ng karagdagang lohika sa isang klase. gumagana ang bawat pamamaraan sa isa o ilan sa mga ito, na nagiging sanhi ng maraming pagkakaisa sa loob ng klase (na eksakto kung paano ito dapat, dahil ang klase ay dapat na isang pinag-isang kabuuan). Bilang resulta, ang pagtaas ng pagkakaisa ng isang klase ay humahantong sa isang pagbawas sa laki ng klase, at, siyempre, ang bilang ng mga klase ay tumataas. Nakakainis ito para sa ilang tao, dahil kailangan mong bumasang mabuti sa mga file ng klase nang higit pa upang makita kung paano gumagana ang isang partikular na malaking gawain. Higit sa lahat, ang bawat klase ay isang maliit na module na dapat ay minimal na nauugnay sa iba. Binabawasan ng paghihiwalay na ito ang bilang ng mga pagbabagong kailangan nating gawin kapag nagdaragdag ng karagdagang lohika sa isang klase. gumagana ang bawat pamamaraan sa isa o ilan sa mga ito, na nagiging sanhi ng maraming pagkakaisa sa loob ng klase (na eksakto kung paano ito dapat, dahil ang klase ay dapat na isang pinag-isang kabuuan). Bilang resulta, ang pagtaas ng pagkakaisa ng isang klase ay humahantong sa isang pagbawas sa laki ng klase, at, siyempre, ang bilang ng mga klase ay tumataas. Nakakainis ito para sa ilang tao, dahil kailangan mong bumasang mabuti sa mga file ng klase nang higit pa upang makita kung paano gumagana ang isang partikular na malaking gawain. Higit sa lahat, ang bawat klase ay isang maliit na module na dapat ay minimal na nauugnay sa iba. Binabawasan ng paghihiwalay na ito ang bilang ng mga pagbabagong kailangan nating gawin kapag nagdaragdag ng karagdagang lohika sa isang klase. Ang pagkakaisa ay humahantong sa isang pagbawas sa laki ng klase, at, siyempre, ang bilang ng mga klase ay tumataas. Nakakainis ito para sa ilang tao, dahil kailangan mong bumasang mabuti sa mga file ng klase nang higit pa upang makita kung paano gumagana ang isang partikular na malaking gawain. Higit sa lahat, ang bawat klase ay isang maliit na module na dapat ay minimal na nauugnay sa iba. Binabawasan ng paghihiwalay na ito ang bilang ng mga pagbabagong kailangan nating gawin kapag nagdaragdag ng karagdagang lohika sa isang klase. Ang pagkakaisa ay humahantong sa isang pagbawas sa laki ng klase, at, siyempre, ang bilang ng mga klase ay tumataas. Nakakainis ito para sa ilang tao, dahil kailangan mong bumasang mabuti sa mga file ng klase nang higit pa upang makita kung paano gumagana ang isang partikular na malaking gawain. Higit sa lahat, ang bawat klase ay isang maliit na module na dapat ay minimal na nauugnay sa iba. Binabawasan ng paghihiwalay na ito ang bilang ng mga pagbabagong kailangan nating gawin kapag nagdaragdag ng karagdagang lohika sa isang klase.

Mga bagay

Encapsulation

Dito muna natin pag-uusapan ang isang prinsipyo ng OOP: encapsulation. Ang pagtatago ng pagpapatupad ay hindi katumbas ng paglikha ng isang paraan upang i-insulate ang mga variable (walang iniisip na paghihigpit sa pag-access sa pamamagitan ng mga indibidwal na pamamaraan, getter, at setter, na hindi maganda, dahil ang buong punto ng encapsulation ay nawala). Ang pagtatago ng access ay naglalayong bumuo ng mga abstraction, iyon ay, ang klase ay nagbibigay ng mga nakabahaging kongkretong pamamaraan na ginagamit namin upang gumana sa aming data. At hindi kailangang malaman ng user nang eksakto kung paano namin ginagawa ang data na ito — gumagana ito at sapat na iyon.

Batas ng Demeter

Maaari din nating isaalang-alang ang Batas ng Demeter: ito ay isang maliit na hanay ng mga panuntunan na tumutulong sa pamamahala ng pagiging kumplikado sa antas ng klase at pamamaraan. Ipagpalagay na mayroon kaming isang bagay na Kotse , at mayroon itong paraan ng paglipat(Object arg1, Object arg2) . Ayon sa Batas ng Demeter, ang pamamaraang ito ay limitado sa pagtawag:

• mga pamamaraan ng mismong bagay ng Kotse (sa madaling salita, ang bagay na "ito");
• pamamaraan ng mga bagay na nilikha sa loob ng paraan ng paglipat ;
• pamamaraan ng mga bagay na ipinasa bilang mga argumento ( arg1 , arg2 );
• mga pamamaraan ng panloob na mga bagay ng Kotse (muli, "ito").

Sa madaling salita, ang Batas ng Demeter ay katulad ng maaaring sabihin ng mga magulang sa isang bata: "maaari kang makipag-usap sa iyong mga kaibigan, ngunit hindi sa mga estranghero".

Istraktura ng data

Ang istraktura ng data ay isang koleksyon ng mga kaugnay na elemento. Kapag isinasaalang-alang ang isang bagay bilang isang istraktura ng data, mayroong isang hanay ng mga elemento ng data na pinapatakbo ng mga pamamaraan. Ang pagkakaroon ng mga pamamaraang ito ay tahasang ipinapalagay. Iyon ay, ang istraktura ng data ay isang bagay na ang layunin ay mag-imbak at magtrabaho kasama (iproseso) ang nakaimbak na data. Ang pangunahing pagkakaiba nito mula sa isang regular na bagay ay ang isang ordinaryong bagay ay isang koleksyon ng mga pamamaraan na gumagana sa mga elemento ng data na implicitly na ipinapalagay na umiiral. Naiintindihan mo ba? Ang pangunahing aspeto ng isang ordinaryong bagay ay mga pamamaraan. Ang mga panloob na variable ay nagpapadali sa kanilang tamang operasyon. Ngunit sa isang istraktura ng data, ang mga pamamaraan ay naroroon upang suportahan ang iyong trabaho sa mga nakaimbak na elemento ng data, na pinakamahalaga rito. Ang isang uri ng istraktura ng data ay isang data transfer object (DTO). Ito ay isang klase na may mga pampublikong variable at walang mga pamamaraan (o mga paraan lamang para sa pagbabasa/pagsusulat) na ginagamit upang maglipat ng data kapag nagtatrabaho sa mga database, pag-parse ng mga mensahe mula sa mga socket, atbp. Ang data ay hindi karaniwang nakaimbak sa mga naturang bagay sa loob ng mahabang panahon. Ito ay halos agad na na-convert sa uri ng entity na gumagana ang aming application. Ang isang entity, sa turn, ay isa ring istraktura ng data, ngunit ang layunin nito ay lumahok sa lohika ng negosyo sa iba't ibang antas ng aplikasyon. Ang layunin ng isang DTO ay maghatid ng data papunta/mula sa application. Halimbawa ng isang DTO: ay isa ring istruktura ng data, ngunit ang layunin nito ay lumahok sa lohika ng negosyo sa iba't ibang antas ng aplikasyon. Ang layunin ng isang DTO ay maghatid ng data papunta/mula sa application. Halimbawa ng isang DTO: ay isa ring istruktura ng data, ngunit ang layunin nito ay lumahok sa lohika ng negosyo sa iba't ibang antas ng aplikasyon. Ang layunin ng isang DTO ay maghatid ng data papunta/mula sa application. Halimbawa ng isang DTO:

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

Ang lahat ay tila sapat na malinaw, ngunit dito natutunan natin ang tungkol sa pagkakaroon ng mga hybrid. Ang mga hybrid ay mga bagay na may mga pamamaraan para sa paghawak ng mahalagang lohika, pag-iimbak ng mga panloob na elemento, at kasama rin ang mga pamamaraan ng accessor (kumuha/magtakda). Ang ganitong mga bagay ay magulo at nagpapahirap sa pagdaragdag ng mga bagong pamamaraan. Dapat mong iwasan ang mga ito, dahil hindi malinaw kung para saan ang mga ito - pag-iimbak ng mga elemento o pagpapatupad ng lohika?

Mga prinsipyo ng paglikha ng mga variable

Pag-isipan natin ng kaunti ang tungkol sa mga variable. Higit na partikular, isipin natin kung anong mga prinsipyo ang nalalapat kapag nililikha ang mga ito:

1. Sa isip, dapat mong ideklara at simulan ang isang variable bago ito gamitin (huwag lumikha ng isa at kalimutan ang tungkol dito).
2. Hangga't maaari, ideklara ang mga variable bilang pinal upang maiwasan ang pagbabago ng kanilang halaga pagkatapos ng pagsisimula.
3. Huwag kalimutan ang tungkol sa mga counter variable, na karaniwan naming ginagamit sa ilang uri ng for loop. Iyon ay, huwag kalimutang i-zero ang mga ito. Kung hindi, maaaring masira ang lahat ng ating lohika.
4. Dapat mong subukang simulan ang mga variable sa constructor.
5. Kung may mapagpipilian sa pagitan ng paggamit ng object na may reference o wala ( new SomeObject() ), opt for without, dahil pagkatapos gamitin ang object ay tatanggalin ito sa susunod na cycle ng koleksyon ng basura at hindi masasayang ang mga mapagkukunan nito.
6. Panatilihing maikli hangga't maaari ang buhay ng isang variable (ang distansya sa pagitan ng paggawa ng variable at ang huling beses na ito ay na-reference).
7. Magsimula ng mga variable na ginamit sa isang loop bago ang loop, hindi sa simula ng pamamaraan na naglalaman ng loop.
8. Palaging magsimula sa pinakalimitadong saklaw at palawakin lamang kung kinakailangan (dapat mong subukang gumawa ng variable bilang lokal hangga't maaari).
9. Gamitin ang bawat variable para sa isang layunin lamang.
10. Iwasan ang mga variable na may nakatagong layunin, hal. isang variable na split sa pagitan ng dalawang gawain — nangangahulugan ito na ang uri nito ay hindi angkop para sa paglutas ng isa sa mga ito.

Paraan

mula sa pelikulang "Star Wars: Episode III - Revenge of the Sith" (2005)

Magpatuloy tayo nang direkta sa pagpapatupad ng ating lohika, ibig sabihin, sa mga pamamaraan.

1. Rule #1 — Compactness. Sa isip, ang isang paraan ay hindi dapat lumampas sa 20 linya. Nangangahulugan ito na kung ang isang pampublikong pamamaraan ay "lumo" nang malaki, kailangan mong pag-isipan ang paghiwa-hiwalayin ang lohika at ilipat ito sa magkahiwalay na pribadong pamamaraan.

2. Panuntunan #2 — kung , else , while at iba pang mga statement ay hindi dapat magkaroon ng mabibigat na nested block: maraming nesting ang makabuluhang binabawasan ang pagiging madaling mabasa ng code. Sa isip, dapat ay mayroon kang hindi hihigit sa dalawang nested {} blocks.

   At kanais-nais din na panatilihing compact at simple ang code sa mga bloke na ito.

3. Panuntunan #3 — Ang isang pamamaraan ay dapat magsagawa lamang ng isang operasyon. Iyon ay, kung ang isang pamamaraan ay nagsasagawa ng lahat ng uri ng kumplikadong lohika, hinahati namin ito sa mga submethod. Bilang resulta, ang pamamaraan mismo ay magiging isang harapan na ang layunin ay tawagan ang lahat ng iba pang mga operasyon sa tamang pagkakasunud-sunod.

   Ngunit paano kung ang operasyon ay tila napakasimple upang ilagay sa isang hiwalay na paraan? Totoo, kung minsan ay parang pagpapaputok ng kanyon sa mga maya, ngunit ang maliliit na pamamaraan ay nagbibigay ng maraming pakinabang:

   • Mas mahusay na pag-unawa sa code;
   • Ang mga pamamaraan ay may posibilidad na maging mas kumplikado habang umuunlad ang pag-unlad. Kung ang isang paraan ay simple sa simula, kung gayon ito ay magiging mas madali upang gawing kumplikado ang pag-andar nito;
   • Nakatago ang mga detalye ng pagpapatupad;
   • Mas madaling muling paggamit ng code;
   • Mas maaasahang code.

4. Ang stepdown rule — Ang code ay dapat basahin mula sa itaas hanggang sa ibaba: habang mas mababa ang iyong nabasa, mas malalim ang iyong pagsisiyasat sa lohika. At kabaligtaran, ang mas mataas na pupunta ka, mas abstract ang mga pamamaraan. Halimbawa, ang mga pahayag ng switch ay medyo hindi siksik at hindi kanais-nais, ngunit kung hindi mo maiiwasan ang paggamit ng switch, dapat mong subukang ilipat ito sa pinakamababa hangga't maaari, sa pinakamababang antas ng mga pamamaraan.

5. Mga argumento ng pamamaraan — Ano ang perpektong numero? Sa isip, wala sa lahat :) Ngunit nangyayari ba talaga iyon? Iyon ay sinabi, dapat mong subukan na magkaroon ng kaunting mga argumento hangga't maaari, dahil mas kaunti ang mayroon, mas madaling gumamit ng isang paraan at mas madaling subukan ito. Kapag may pagdududa, subukang asahan ang lahat ng mga sitwasyon para sa paggamit ng paraan na may malaking bilang ng mga parameter ng input.

6. Bukod pa rito, mainam na paghiwalayin ang mga pamamaraan na mayroong boolean flag bilang isang parameter ng input, dahil ito mismo ay nagpapahiwatig na ang pamamaraan ay gumaganap ng higit sa isang operasyon (kung totoo, pagkatapos ay gumawa ng isang bagay; kung mali, pagkatapos ay gumawa ng isa pa). Tulad ng isinulat ko sa itaas, ito ay hindi mabuti at dapat iwasan kung maaari.

7. Kung ang isang pamamaraan ay may malaking bilang ng mga parameter ng pag-input (ang isang sukdulan ay 7, ngunit dapat mo talagang simulan ang pag-iisip pagkatapos ng 2-3), ang ilan sa mga argumento ay dapat igrupo sa isang hiwalay na bagay.

8. Kung mayroong ilang magkakatulad (na-overload) na mga pamamaraan, dapat na ipasa ang mga katulad na parameter sa parehong pagkakasunud-sunod: pinapabuti nito ang pagiging madaling mabasa at kakayahang magamit.

9. Kapag ipinasa mo ang mga parameter sa isang pamamaraan, dapat mong tiyakin na ang lahat ng ito ay ginagamit, kung hindi, bakit mo ito kailangan? Gupitin ang anumang hindi nagamit na mga parameter mula sa interface at gawin ito.

10. try/catch ay hindi mukhang napakaganda sa kalikasan, kaya magandang ideya na ilipat ito sa isang hiwalay na intermediate na paraan (isang paraan para sa paghawak ng mga pagbubukod):

    
    public void exceptionHandling(SomeObject obj) {
        try {  
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    

Nagsalita ako tungkol sa duplicate na code sa itaas, ngunit hayaan mo akong ulitin muli: Kung mayroon kaming ilang pamamaraan na may paulit-ulit na code, kailangan naming ilipat ito sa isang hiwalay na paraan. Gagawin nitong mas compact ang pamamaraan at ang klase. Huwag kalimutan ang tungkol sa mga patakaran na namamahala sa mga pangalan: ang mga detalye sa kung paano maayos na pangalanan ang mga klase, interface, pamamaraan, at variable ay tatalakayin sa susunod na bahagi ng artikulo. Pero yun lang ang meron ako para sayo ngayon.