Mga panuntunan para sa pagsulat ng code: mula sa paglikha ng isang sistema hanggang sa pagtatrabaho sa mga bagay

Magandang hapon sa lahat: ngayon gusto kong makipag-usap sa iyo tungkol sa tamang pagsulat ng code. Noong una akong nagsimula sa programming, hindi malinaw na nakasulat kahit saan na maaari kang magsulat ng ganito, at kung magsulat ka ng ganito, hahanapin kita at…. Bilang isang resulta, mayroon akong maraming mga katanungan sa aking ulo: kung paano magsulat ng tama, kung anong mga prinsipyo ang dapat sundin sa ito o sa seksyong iyon ng programa, atbp. Well, hindi lahat ay nais na agad na sumisid sa mga libro tulad ng Clean Code, dahil maraming nakasulat sa mga ito, ngunit sa una ay malinaw ang kaunti. At sa oras na matapos mo ang pagbabasa, maaari mong pigilan ang lahat ng pagnanais na mag-code. Kaya batay sa itaas, ngayon gusto kong bigyan ka ng isang maliit na gabay (isang hanay ng mga maliliit na rekomendasyon) para sa pagsusulat ng mas mataas na antas ng code. Sa artikulong ito tatalakayin natin ang mga pangunahing panuntunan at konsepto na nauugnay sa paglikha ng isang system at pagtatrabaho sa mga interface, klase at mga bagay. Ang pagbabasa ng materyal na ito ay hindi magdadala sa iyo ng maraming oras at, umaasa ako, ay hindi ka hahayaang magsawa. Pupunta ako mula sa itaas hanggang sa ibaba, iyon ay, mula sa pangkalahatang istraktura ng application hanggang sa mas tiyak na mga detalye.

Sistema

Ang pangkalahatang kanais-nais na mga katangian ng system ay:

• minimal na kumplikado - dapat na iwasan ang sobrang kumplikadong mga proyekto. Ang pangunahing bagay ay pagiging simple at kalinawan (pinakamahusay = simple);
• kadalian ng pagpapanatili - kapag lumilikha ng isang application, dapat mong tandaan na ito ay kailangang suportahan (kahit na ito ay hindi ikaw), kaya ang code ay dapat na malinaw at halata;
• ang mahinang pagkabit ay ang pinakamababang bilang ng mga koneksyon sa pagitan ng iba't ibang bahagi ng programa (pinakamataas na paggamit ng mga prinsipyo ng OOP);
• muling paggamit - pagdidisenyo ng isang sistema na may kakayahang muling gamitin ang mga fragment nito sa ibang mga aplikasyon;
• maaaring dalhin - ang sistema ay dapat na madaling iakma sa ibang kapaligiran;
• solong istilo - pagdidisenyo ng isang sistema sa isang solong istilo sa iba't ibang mga fragment nito;
• extensibility (scalability) - pagpapabuti ng system nang hindi nilalabag ang pangunahing istraktura nito (kung magdadagdag ka o magpalit ng ilang fragment, hindi ito dapat makaapekto sa iba).

Halos imposible na bumuo ng isang application na hindi nangangailangan ng mga pagbabago, nang walang pagdaragdag ng pag-andar. Patuloy nating kakailanganing magpakilala ng mga bagong elemento upang ang ating utak ay makasabay sa mga panahon. At dito pumapasok ang scalability . Ang scalability ay mahalagang pagpapalawak ng application, pagdaragdag ng bagong functionality, pagtatrabaho sa mas maraming mapagkukunan (o, sa madaling salita, na may mas maraming pag-load). Iyon ay, dapat tayong sumunod sa ilang mga patakaran, tulad ng pagbabawas ng pagkabit ng sistema sa pamamagitan ng pagtaas ng modularity, upang mas madaling magdagdag ng bagong lohika.

Mga yugto ng disenyo ng system

1. Sistema ng software - pagdidisenyo ng isang aplikasyon sa pangkalahatang anyo.
2. Paghihiwalay sa mga subsystem/package - pagtukoy sa lohikal na paghihiwalay ng mga bahagi at pagtukoy sa mga tuntunin ng pakikipag-ugnayan sa pagitan ng mga ito.
3. Paghahati ng mga subsystem sa mga klase - paghahati ng mga bahagi ng system sa mga partikular na klase at interface, pati na rin ang pagtukoy sa pakikipag-ugnayan sa pagitan nila.
4. Ang paghahati ng mga klase sa mga pamamaraan ay isang kumpletong kahulugan ng mga kinakailangang pamamaraan para sa isang klase, batay sa gawain ng klase na ito. Disenyo ng pamamaraan - detalyadong kahulugan ng pag-andar ng mga indibidwal na pamamaraan.

Karaniwan, ang mga ordinaryong developer ang may pananagutan para sa disenyo, at ang arkitekto ng application ay responsable para sa mga item na inilarawan sa itaas.

Mga pangunahing prinsipyo at konsepto ng disenyo ng system

Lazy initialization idiom Ang isang application ay hindi gumugugol ng oras sa paglikha ng isang bagay hanggang sa ito ay ginagamit, na nagpapabilis sa proseso ng pagsisimula at nakakabawas sa pagkarga ng basurero. Ngunit hindi ka dapat lumayo dito, dahil maaari itong humantong sa isang paglabag sa modularity. Maaaring sulit na ilipat ang lahat ng hakbang sa disenyo sa isang partikular na bahagi, halimbawa, pangunahing, o sa isang klase na gumagana tulad ng isang pabrika . Ang isa sa mga aspeto ng magandang code ay ang kawalan ng madalas na paulit-ulit, boilerplate code. Bilang isang patakaran, ang naturang code ay inilalagay sa isang hiwalay na klase upang ito ay matawag sa tamang oras. AOP Hiwalay, gusto kong banggitin ang aspect-oriented programming . Ito ay programming sa pamamagitan ng pagpapakilala ng end-to-end logic, iyon ay, ang paulit-ulit na code ay inilalagay sa mga klase - mga aspeto, at tinatawag kapag naabot ang ilang mga kundisyon. Halimbawa, kapag nag-a-access ng isang pamamaraan na may isang tiyak na pangalan o nag-a-access ng isang variable ng isang tiyak na uri. Minsan ang mga aspeto ay maaaring nakakalito, dahil hindi agad malinaw kung saan tinawag ang code, ngunit gayunpaman, ito ay isang napaka-kapaki-pakinabang na pag-andar. Sa partikular, kapag nag-cache o nagla-log: idinaragdag namin ang pagpapaandar na ito nang hindi nagdaragdag ng karagdagang lohika sa mga regular na klase. Maaari kang magbasa ng higit pa tungkol sa OAP dito . 4 Mga Panuntunan para sa Pagdidisenyo ng Simpleng Arkitektura Ayon kay Kent Beck

1. Expressiveness - ang pangangailangan para sa isang malinaw na ipinahayag na layunin ng klase, ay nakakamit sa pamamagitan ng tamang pagpapangalan, maliit na sukat at pagsunod sa prinsipyo ng solong responsibilidad (titingnan natin ito nang mas detalyado sa ibaba).
2. Ang isang minimum na mga klase at pamamaraan - sa iyong pagnanais na hatiin ang mga klase sa bilang maliit at unidirectional hangga't maaari, maaari kang pumunta ng masyadong malayo (antipattern - shotgunning). Ang prinsipyong ito ay nangangailangan ng pagpapanatiling compact ang system at hindi masyadong lumayo, na lumilikha ng klase para sa bawat pagbahing.
3. Kakulangan ng pagdoble - ang sobrang code na nakakalito ay isang senyales ng hindi magandang disenyo ng system at inilipat sa isang hiwalay na lugar.
4. Pagpapatupad ng lahat ng mga pagsubok - ang isang sistema na nakapasa sa lahat ng mga pagsubok ay kinokontrol, dahil ang anumang pagbabago ay maaaring humantong sa isang pagkabigo ng mga pagsubok, na maaaring ipakita sa amin na ang isang pagbabago sa panloob na lohika ng pamamaraan ay humantong din sa isang pagbabago sa inaasahang pag-uugali .

SOLID Kapag nagdidisenyo ng isang sistema, ito ay nagkakahalaga ng pagsasaalang-alang sa mga kilalang prinsipyo ng SOLID: S - solong responsibilidad - ang prinsipyo ng solong responsibilidad; O - open-closed - prinsipyo ng openness/closeness; L - Liskov substitution - Barbara Liskov's substitution principle; I - interface segregation - ang prinsipyo ng interface separation; D - dependency inversion - prinsipyo ng dependency inversion; Hindi namin tatalakayin ang bawat prinsipyo nang partikular (ito ay medyo lampas sa saklaw ng artikulong ito, ngunit maaari mong malaman ang higit pa dito

Interface

Marahil ang isa sa pinakamahalagang yugto ng paglikha ng isang sapat na klase ay ang paglikha ng isang sapat na interface na kumakatawan sa isang mahusay na abstraction na nagtatago sa mga detalye ng pagpapatupad ng klase, at sa parehong oras ay kumakatawan sa isang pangkat ng mga pamamaraan na malinaw na pare-pareho sa bawat isa. . Tingnan natin ang isa sa mga SOLID na prinsipyo - interface segregation : ang mga kliyente (mga klase) ay hindi dapat magpatupad ng mga hindi kinakailangang pamamaraan na hindi nila gagamitin. Iyon ay, kung pinag-uusapan natin ang pagbuo ng mga interface na may isang minimum na bilang ng mga pamamaraan na naglalayong gawin ang tanging gawain ng interface na ito (tulad ng para sa akin, ito ay halos kapareho sa solong responsibilidad ), mas mahusay na lumikha ng isang pares ng mas maliit sa halip na isang bloated interface. Sa kabutihang palad, ang isang klase ay maaaring magpatupad ng higit sa isang interface, tulad ng kaso sa mana. Kailangan mo ring tandaan ang tungkol sa tamang pagpapangalan ng mga interface: dapat ipakita ng pangalan ang gawain nito nang tumpak hangga't maaari. At, siyempre, mas maikli ito, mas kaunting pagkalito ang idudulot nito. Nasa antas ng interface na karaniwang isinusulat ang mga komento para sa dokumentasyon , na, sa turn, ay tumutulong sa amin na ilarawan nang detalyado kung ano ang dapat gawin ng pamamaraan, anong mga argumento ang kinakailangan at kung ano ang ibabalik nito.

Klase

Tingnan natin ang panloob na organisasyon ng mga klase. O sa halip, ilang mga pananaw at panuntunan na dapat sundin kapag gumagawa ng mga klase. Karaniwan, ang isang klase ay dapat magsimula sa isang listahan ng mga variable, na nakaayos sa isang partikular na pagkakasunud-sunod:

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

Susunod ay iba't ibang mga konstruktor sa pagkakasunud-sunod mula sa mas kaunti hanggang sa higit pang mga argumento. Sinusundan sila ng mga pamamaraan mula sa mas bukas na pag-access hanggang sa mga pinaka-sarado: bilang isang panuntunan, 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 klase. Tandaan natin ang isa sa mga prinsipyo ng SOLID - solong responsibilidad . Iisang responsibilidad - ang prinsipyo ng solong 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 tiyakin ito. Iyon ay, batay dito, dapat nating iwasan ang malalaking, namamaga na mga klase (na sa pamamagitan ng kanilang likas na katangian ay isang antipattern - "banal na bagay"), at kung mayroon tayong maraming mga pamamaraan ng magkakaibang, magkakaibang lohika sa isang klase, kailangan nating mag-isip tungkol sa paghahati nito sa dalawang lohikal na bahagi (mga klase). Ito naman, ay magpapahusay sa pagiging madaling mabasa ng code, dahil hindi natin kailangan ng maraming oras upang maunawaan ang layunin ng isang pamamaraan kung alam natin ang tinatayang layunin ng isang partikular na klase. Kailangan mo ring bantayan ang pangalan ng klase : dapat itong sumasalamin sa lohika na nilalaman nito. Sabihin nating, kung mayroon tayong klase na may 20+ salita ang pangalan, kailangan nating isipin ang tungkol sa refactoring. Ang bawat klase na may paggalang sa sarili ay hindi dapat magkaroon ng napakaraming bilang ng mga panloob na variable. Sa katunayan, ang bawat pamamaraan ay gumagana sa isa sa kanila o ilan, na nagiging sanhi ng mas malaking pagkabit sa loob ng klase (na kung ano mismo ang dapat, dahil ang klase ay dapat na bilang isang solong kabuuan). Bilang resulta, ang pagtaas ng pagkakaugnay-ugnay ng isang klase ay humahantong sa pagbaba nito bilang ganoon, at, siyempre, ang aming bilang ng mga klase ay tumataas. Para sa ilan, ito ay nakakainis; kailangan nilang pumunta sa klase nang higit pa upang makita kung paano gumagana ang isang partikular na malaking gawain. Sa iba pang mga bagay, ang bawat klase ay isang maliit na module na dapat ay minimal na konektado 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 isa sa mga prinsipyo ng OOP- encapsulation . Kaya, ang pagtatago ng pagpapatupad ay hindi bumababa sa paglikha ng isang layer ng pamamaraan sa pagitan ng mga variable (walang iniisip na paghihigpit sa pag-access sa pamamagitan ng mga solong pamamaraan, getter at setter, na hindi maganda, dahil ang buong punto ng encapsulation ay nawala). Ang pagtatago ng pag-access ay naglalayong bumuo ng mga abstraction, iyon ay, ang klase ay nagbibigay ng mga karaniwang kongkretong pamamaraan kung saan kami nagtatrabaho sa aming data. Ngunit hindi kailangang malaman ng user nang eksakto kung paano namin ginagawa ang data na ito - gumagana ito, at ayos lang iyon.

Batas ng Demeter

Maaari mo ring isaalang-alang ang Batas ng Demeter: ito ay isang maliit na hanay ng mga panuntunan na tumutulong na pamahalaan ang pagiging kumplikado sa antas ng klase at pamamaraan. Kaya, ipagpalagay natin na mayroon tayong isang bagay Carat mayroon itong pamamaraan - move(Object arg1, Object arg2). Ayon sa Batas ng Demeter, ang pamamaraang ito ay limitado sa pagtawag:

• mga pamamaraan ng mismong bagay Car(sa madaling salita, ito);
• pamamaraan ng mga bagay na nilikha sa move;
• pamamaraan ng mga naipasa na bagay bilang mga argumento - arg1, arg2;
• mga pamamaraan ng panloob na mga bagay Car(ang parehong ito).

Sa madaling salita, ang batas ng Demeter ay parang panuntunan ng mga bata - maaari kang makipag-usap sa mga kaibigan, ngunit hindi sa mga estranghero .

Istraktura ng data

Ang istraktura ng data ay isang koleksyon ng mga kaugnay na elemento. Kung isasaalang-alang ang isang bagay bilang isang istraktura ng data, ito ay isang hanay ng mga elemento ng data na pinoproseso ng mga pamamaraan, ang pagkakaroon nito ay ipinahiwatig nang tahasan. Iyon ay, ito ay isang bagay na ang layunin ay mag-imbak at magpatakbo (iproseso) ang nakaimbak na data. Ang pangunahing pagkakaiba mula sa isang regular na bagay ay ang isang bagay ay isang hanay ng mga pamamaraan na gumagana sa mga elemento ng data na ang pagkakaroon ay ipinahiwatig. Naiintindihan mo ba? Sa isang regular na bagay, ang pangunahing aspeto ay ang mga pamamaraan, at ang mga panloob na variable ay naglalayong sa kanilang tamang operasyon, ngunit sa isang istraktura ng data ito ay kabaligtaran: ang mga pamamaraan ay sumusuporta at tumutulong na gumana sa mga naka-imbak na elemento, na siyang mga pangunahing dito. Ang isang uri ng istruktura ng data ay ang Data Transfer Object (DTO) . Ito ay isang klase na may mga pampublikong variable at walang mga pamamaraan (o mga paraan lamang ng pagbabasa/pagsusulat) na nagpapasa ng data kapag nagtatrabaho sa mga database, gumagana sa pag-parse ng mga mensahe mula sa mga socket, atbp. Karaniwan, ang data sa naturang mga bagay ay hindi nakaimbak ng mahabang panahon at ito ay halos agad na na-convert sa entity kung saan gumagana ang aming application. Ang isang entity, sa turn, ay isa ring istruktura ng data, ngunit ang layunin nito ay lumahok sa lohika ng negosyo sa iba't ibang antas ng application, habang ang DTO ay maghatid ng data papunta/mula sa application. Halimbawa ng 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 malinaw, ngunit dito natutunan natin ang tungkol sa pagkakaroon ng mga hybrid. Ang mga hybrid ay mga bagay na naglalaman ng mga pamamaraan upang mahawakan ang mahalagang lohika at mag-imbak ng mga panloob na elemento at mga paraan ng pag-access (kumuha/magtakda) sa kanila. Ang ganitong mga bagay ay magulo at nagpapahirap sa pagdaragdag ng mga bagong pamamaraan. Hindi mo dapat gamitin ang mga ito, dahil hindi malinaw kung para saan ang mga ito - upang mag-imbak ng mga elemento o magsagawa ng ilang uri ng lohika. Maaari mong basahin ang tungkol sa mga posibleng uri ng mga bagay dito .

Mga prinsipyo ng paglikha ng mga variable

Mag-isip tayo nang kaunti tungkol sa mga variable, o sa halip, isipin kung ano ang maaaring maging mga prinsipyo sa paglikha ng mga ito:

1. Sa isip, dapat mong ideklara at simulan kaagad ang isang variable bago ito gamitin (sa halip na likhain ito 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 (karaniwan ay ginagamit namin ang mga ito sa ilang uri ng loop for, iyon ay, hindi namin dapat kalimutang i-reset ang mga ito, kung hindi, maaari itong masira ang aming buong lohika).
4. Dapat mong subukang simulan ang mga variable sa constructor.
5. Kung may mapagpipilian sa pagitan ng paggamit ng bagay na mayroon o walang reference ( new SomeObject()), piliin ang wala ( ), dahil ang bagay na ito, kapag ginamit, ay tatanggalin sa susunod na koleksyon ng basura at hindi mag-aaksaya ng mga mapagkukunan.
6. Gawing maikli hangga't maaari ang buhay ng mga variable (ang distansya sa pagitan ng paggawa ng variable at ang huling pag-access).
7. Magsimula ng mga variable na ginamit sa isang loop kaagad bago ang loop, sa halip na sa simula ng paraan na naglalaman ng loop.
8. Palaging magsimula sa pinakalimitadong saklaw at palawakin lamang ito kung kinakailangan (dapat mong subukang gawing lokal ang variable hangga't maaari).
9. Gamitin ang bawat variable para sa isang layunin lamang.
10. Iwasan ang mga variable na may mga nakatagong kahulugan (ang variable ay napunit sa pagitan ng dalawang gawain, na nangangahulugang ang uri nito ay hindi angkop para sa paglutas ng isa sa mga ito).

Paraan

Direkta tayong lumipat sa pagpapatupad ng ating lohika, ibig sabihin, sa mga pamamaraan.

1. Ang unang panuntunan ay compactness. Sa isip, ang isang paraan ay hindi dapat lumagpas sa 20 linya, kaya kung, sabihin nating, ang isang pampublikong pamamaraan ay "bumukol" nang malaki, kailangan mong isipin ang paglipat ng pinaghiwalay na lohika sa mga pribadong pamamaraan.

2. Ang pangalawang panuntunan ay ang mga bloke sa commands if, else, whileat iba pa ay hindi dapat mataas ang nested: ito ay makabuluhang binabawasan ang pagiging madaling mabasa ng code. Sa isip, ang nesting ay dapat na hindi hihigit sa dalawang bloke {}.

   Maipapayo rin na gawing compact at simple ang code sa mga block na ito.

3. Ang pangatlong tuntunin ay ang isang pamamaraan ay dapat magsagawa lamang ng isang operasyon. Iyon ay, kung ang isang pamamaraan ay gumaganap ng kumplikado, iba't ibang lohika, hinahati namin ito sa mga submethod. Bilang isang resulta, ang pamamaraan mismo ay magiging isang harapan, ang layunin kung saan ay tawagan ang lahat ng iba pang mga operasyon sa tamang pagkakasunud-sunod.

   Ngunit paano kung ang operasyon ay tila masyadong simple upang lumikha ng isang hiwalay na paraan? Oo, kung minsan ay parang pagbaril ng mga maya mula sa isang kanyon, ngunit ang maliliit na pamamaraan ay nagbibigay ng maraming benepisyo:

   • mas madaling pagbabasa ng code;
   • Ang mga pamamaraan ay may posibilidad na maging mas kumplikado sa kurso ng pag-unlad, at kung ang pamamaraan sa una ay simple, ang pagpapakumplikado sa pag-andar nito ay magiging mas madali;
   • pagtatago ng mga detalye ng pagpapatupad;
   • pagpapadali sa muling paggamit ng code;
   • mas mataas na pagiging maaasahan ng code.

4. Ang pababang panuntunan ay ang code ay dapat basahin mula sa itaas hanggang sa ibaba: mas mababa, mas malaki ang lalim ng lohika, at vice versa, mas mataas, mas abstract ang mga pamamaraan. Halimbawa, ang mga command ng switch ay medyo hindi siksik at hindi kanais-nais, ngunit kung hindi mo magagawa nang hindi gumagamit ng switch, dapat mong subukang ilipat ito nang mas mababa hangga't maaari, sa pinakamababang antas ng mga pamamaraan.

5. Mga argumento ng pamamaraan - ilan ang perpekto? Sa isip, wala talaga)) Ngunit nangyayari ba talaga iyon? Gayunpaman, dapat mong subukan na magkaroon ng kaunti sa mga ito hangga't maaari, dahil mas kaunti ang mayroon, mas madaling gamitin ang pamamaraang ito at mas madaling subukan ito. Kung may pagdududa, subukang hulaan ang lahat ng mga sitwasyon para sa paggamit ng isang paraan na may malaking bilang ng mga input argument.

6. Hiwalay, gusto kong i-highlight ang mga pamamaraan na mayroong boolean flag bilang input argument , dahil natural na ipinahihiwatig nito na ang pamamaraang ito ay nagpapatupad ng higit sa isang operasyon (kung totoo ay isa, mali - 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 papasok na argumento (ang matinding halaga ay 7, ngunit dapat mong isipin ito pagkatapos ng 2-3), kailangan mong pagsamahin ang ilang mga argumento sa isang hiwalay na bagay.

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

9. Kapag ipinasa mo ang mga parameter sa isang pamamaraan, dapat mong siguraduhin na ang lahat ng ito ay gagamitin, kung hindi, para saan ang argumento? Gupitin ito sa interface at iyon na.

10. try/catchHindi ito mukhang napakaganda sa pamamagitan ng likas na katangian nito, kaya isang magandang hakbang ay ilipat ito sa isang intermediate na hiwalay na paraan (paraan para sa paghawak ng mga pagbubukod):

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

Nagsalita ako tungkol sa pag-uulit ng code sa itaas, ngunit idaragdag ko ito dito: Kung mayroon tayong ilang mga pamamaraan na may paulit-ulit na bahagi ng code, kailangan nating ilipat ito sa isang hiwalay na paraan, na magpapataas sa pagiging compactness ng parehong pamamaraan at ng klase. At huwag kalimutan ang tungkol sa mga tamang pangalan. Sasabihin ko sa iyo ang mga detalye ng tamang pagpapangalan ng mga klase, interface, pamamaraan at variable sa susunod na bahagi ng artikulo. At iyon lang ang mayroon ako para sa araw na ito. Mga panuntunan sa code: ang kapangyarihan ng wastong pagbibigay ng pangalan, mabuti at masamang komento