1. Syntactic sugar
Gustung-gusto ng mga programmer kapag ang ilang kumplikadong code o lohika ay maaaring isulat sa ilang linya, na ginagawang compact at nababasa ang code. At ang mga tagalikha ng mga programming language kung minsan ay tumutulong dito.
Ang isang makinis na feature ng wika na nagbibigay-daan sa iyong kumuha ng shortcut (magsulat ng mas kaunting code) ay tinatawag na syntactic sugar . Ngunit, sa totoo lang, napakakaunti nito sa Java.
Ginawa ng mga tagalikha ng Java ang lahat ng kanilang makakaya upang maalis ang anumang kalabisan sa Java. Kung hinahayaan ka ng C++ na gumawa ng isang bagay sa 20 paraan, hinahayaan ka ng Java na gawin ito sa isang paraan lamang.
Ngunit hindi nagustuhan ng Java programmer o ng mga tagalikha ng Java ang kawalan ng kalayaan. At kung minsan ang asukal ay nagpapadali sa buhay para sa mga ordinaryong tao tulad mo at ako.
Siyanga pala, nakatagpo ka na ng ilang syntactic sugar: autoboxing at unboxing . Ihambing natin:
Mahabang code | Compact na code |
---|---|
|
|
|
|
|
|
Sa halip na ang mahabang code tulad ng sa kaliwa, maaari mong isulat ang mas compact na code sa kanan. At ang matalinong Java compiler ay bubuo ng verbose na bersyon ng code batay sa maikling bersyon ng code. Ganito talaga ang syntactic sugar.
2. Hinuha ng uri ng variable: ang var
keyword
Sa Java 11, ang compiler ay naging mas matalino at maaari na ngayong matukoy ang uri ng isang ipinahayag na variable batay sa uri ng halaga na itinalaga dito . Sa code, ganito ang hitsura:
var name = value;
Nasaan name
ang pangalan ng isang bagong variable, ang value ay ang paunang halaga nito, at var
isang keyword na ginamit upang ideklara ang variable. Magiging pareho ang uri ng variable ng pangalan sa uri ng value na itinalaga dito.
Mga halimbawa:
Paano natin nakikita ang code | Ano ang nakikita ng compiler |
---|---|
|
|
|
|
|
|
|
|
|
|
Ang compiler mismo ang tumutukoy, o naghihinuha, ang uri ng variable batay sa halagang itinalaga dito.
Mainit na pinagtatalunan ng mga programmer kung magdaragdag ng ganoong feature sa wika. Maraming tao ang natatakot na var
maabuso iyon at ang pagiging madaling mabasa ng code ay magdurusa bilang resulta.
Mayroong butil ng katotohanan dito, kaya pinakamahusay na gamitin var
kung saan pinapataas nito ang pagiging madaling mabasa ng code. Halimbawa, ang mga ito sa dalawang kaso:
Kaso 1: Kung titingnan ang value na itinalaga sa variable, malinaw agad ang uri ng variable
Code | Paliwanag |
---|---|
|
Ang variable ay isangInputStream |
|
Ang variable ay aString |
Sa mga kasong ito, hindi mo dapat gamitin ang var
. Well, ano ang uri ng variable?
Code | Paliwanag |
---|---|
|
Mahirap matukoy ang uri ng variable |
|
Mahirap matukoy ang uri ng variable |
Kaso 2: Ang uri ng variable ay hindi mahalaga para sa pag-unawa sa code
Ang code ay madalas na hindi kailangang tumawag ng mga pamamaraan sa isang variable, hal. kapag ang isang variable ay ginagamit lamang upang pansamantalang mag-imbak ng isang bagay. Sa kasong ito, var
tiyak na hindi binabawasan ng paggamit ang pagiging madaling mabasa ng code:
Mahabang code | Compact na code |
---|---|
|
Nakakuha kami ng metadata mula sa stream stream at na-save ito sa storage repository. Ang data partikular na uri ng variable ay hindi mahalaga. |
Ang ibig sabihin ng ginto
Ngayon ay magbibigay ako ng tatlong paraan upang isulat ang parehong code. Ang paggamit var
ay ang pinakamahusay na pagpipilian.
Code | Tandaan |
---|---|
|
Masyadong compact |
|
Tama lang |
|
Masyadong detalyado |
Ang paglipat mula sa bersyon na may 1 linya patungo sa bersyon sa 2 linya, ginawa naming mas madaling mabasa ang code sa pamamagitan ng paggamit ng variable na pangalan ( headerInfo
). Ngayon ay malinaw na ang pamamaraan ay hindi lamang nagbabalik ng impormasyon sa meta, ngunit ang impormasyon ng header.
Ang ikatlong bersyon ay sobrang verbose. Ang katotohanan na headerInfo
ay isang FileMetaInfo
ay medyo malinaw mula sa getFileMetaInfo()
pamamaraan. Ang layunin ng meta information ay mas kawili-wili.
3. Pag-aalis ng uri sa diamond operator:<>
Bago pa man var
lumitaw ang operator, may mga pagtatangka na turuan ang compiler kung paano maghinuha ng mga uri ng koleksyon. Sasang-ayon ka na ang notasyong ito ay mukhang medyo kalabisan:
ArrayList<String> list = new ArrayList<String>();
Simula sa ikapitong bersyon ng Java, kapag nagsusulat ng uri ng koleksyon, maaari mong alisin ang uri ng mga elemento ng koleksyon kung ito ay tinukoy kapag nagdedeklara ng variable. Sa madaling salita, ang code sa itaas ay maaaring isulat sa isang bahagyang pinaikling anyo:
ArrayList<String> list = new ArrayList<>();
Gaya ng nakikita mo, hindi mo na kailangang isulat ang String sa pangalawang pagkakataon. Hindi kasing cool ng operator ng var, ngunit tila progreso sa panahong iyon.
Ang mga walang laman na anggulong bracket sa uri ng koleksyon ay tinawag na diamond operator , dahil ang dalawang anggulong bracket ay malabo na kahawig ng isang brilyante.
Hindi kanais-nais na gamitin ang var
keyword at ang operator ng brilyante sa parehong oras :
var list = new ArrayList<>();
Walang impormasyon sa lahat tungkol sa uri ng mga elemento na nakaimbak sa koleksyon, at ang uri ng koleksyon ay ArrayList < Object >.
4. Double curly braces
Tandaan ang mabilis na pagsisimula ng array?
Inilista lang namin ang mga halaga sa mga kulot na brace, tulad nito:
Mga halimbawa |
---|
|
|
Nagustuhan ng mga tagalikha ng Java ang ideya ng paggamit ng mga kulot na brace upang pasimplehin ang pagsusulat ng mga elemento ng isang array. Ngunit ano ang tungkol sa mga koleksyon?
Ang mga tagalikha ng Java ay may sapat na malikhaing pag-iisip para sa mga koleksyon din, na nagpapahintulot sa kanila na gumamit ng isang trick na may double curly braces.
May asukal | Walang asukal |
---|---|
|
|
Kung ang compiler ay nakatagpo ng code tulad ng sa halimbawa sa kaliwa, pagkatapos ay i-convert ito sa code sa kanan.
Ang code ay hindi nagiging mas compact. Ang mga matitipid dito ay medyo hindi gaanong mahalaga: hindi mo kailangang magsulat list
sa bawat oras. Makakatulong ito kung napakahaba ng variable na pangalan.
Ngunit kung makatagpo ka ng code na tulad nito sa isang proyekto, huwag magtaka 🙂
GO TO FULL VERSION