1. Синтактична захар
Програмистите обичат, когато сложен code or логика могат да бъдат написани в няколко реда, което прави codeа компактен и четим. И създателите на езици за програмиране понякога помагат с това.
Елегантна езикова функция, която ви позволява да използвате пряк път (пишете по-малко code), се нарича синтактична захар . Но, честно казано, в Java има много малко от него.
Създателите на Java направиха всичко по сorте си, за да премахнат всяHowви излишъци в Java. Ако C++ ви позволява да правите нещо по 20 начина, тогава Java ви позволява да го правите само по един начин.
Но нито Java програмистите, нито създателите на Java харесаха липсата на свобода. И понякога захарта улеснява живота на обикновените хора като теб и мен.
Между другото, вече сте се сблъскали с малко синтактична захар: автоматично поставяне в кутия и разопаковане . Да сравним:
Дълъг code | Компактен code |
---|---|
|
|
|
|
|
|
Вместо дългия code като вляво, можете да напишете по-компактния code вдясно. А интелигентният Java компилатор ще генерира подробната version на codeа въз основа на кратката version на codeа. Точно това е синтактичната захар.
2. Извод за тип променлива: var
ключовата дума
В Java 11 компилаторът стана още по-умен и вече може да определи типа на декларирана променлива въз основа на типа на присвоената й стойност . В code изглежда така:
var name = value;
Където name
е името на нова променлива, value е нейната първоначална стойност и var
е ключова дума, използвана за деклариране на променливата. Типът на променливата име ще бъде същият като типа на присвоената й стойност.
Примери:
Как виждаме codeа | Какво вижда компилаторът |
---|---|
|
|
|
|
|
|
|
|
|
|
Самият компилатор определя or извежда типа на променливата въз основа на стойността, която й е присвоена.
Програмистите спориха горещо дали да добавят такава функция към езика. Много хора се страхуваха, че това var
ще бъде злоупотребено и че четимостта на codeа ще пострада в резултат.
В това има зрънце истина, така че е най-добре да се използва var
там, където увеличава четливостта на codeа. Например тези в два случая:
Случай 1: Разглеждайки стойността, присвоена на променливата, типът на променливата веднага става ясен
Код | Обяснение |
---|---|
|
Променливата е anInputStream |
|
Променливата е aString |
В тези случаи не трябва да използвате var
. Е, Howъв е типът на променливата?
Код | Обяснение |
---|---|
|
Трудно е да се определи типа на променливата |
|
Трудно е да се определи типа на променливата |
Случай 2: Типът на променливата не е важен за разбирането на codeа
Кодът често няма нужда да извиква методи на променлива, например когато променлива просто се използва за временно съхраняване на нещо. В този случай използването var
определено не намалява четливостта на codeа:
Дълъг code | Компактен code |
---|---|
|
Получихме метаданни от stream потока и ги запазихме в storage хранorщето. Конкретният тип на променливата data не е важен. |
Златната среда
Сега ще дам три начина за писане на един и същ code. Използването var
би било най-добрият вариант.
Код | Забележка |
---|---|
|
Твърде компактен |
|
Точно |
|
Твърде подробно |
Преминавайки от versionта с 1 ред към versionта с 2 реда, направихме codeа малко по-четлив, като използвахме име на променлива ( headerInfo
). Сега е ясно, че методът връща не само мета информация, но и информация за заглавка.
Третата version е твърде многословна. Фактът, че headerInfo
е a, FileMetaInfo
вече е доста ясен от getFileMetaInfo()
метода. Целта на мета информацията е много по-интересна.
3. Изпускане на типа с оператора диамант:<>
Дори преди да var
се появи операторът, имаше опити да се научи компилаторът How да извежда типове колекции. Ще се съгласите, че тази нотация изглежда малко излишна:
ArrayList<String> list = new ArrayList<String>();
Започвайки от седмата version на Java, когато пишете тип колекция, можете да пропуснете типа на елементите на колекцията, ако е бил посочен при декларирането на променлива. С други думи, codeът по-горе може да бъде написан в леко съкратена форма:
ArrayList<String> list = new ArrayList<>();
Както можете да видите, вече не е необходимо да пишете String втори път. Не толкова готино, колкото с оператора var, но изглеждаше като напредък по онова време.
Празните ъглови скоби в типа колекция бяха наречени диамант оператор , тъй като двете ъглови скоби смътно наподобяват диамант.
Не е желателно да използвате var
ключовата дума и оператора диамант едновременно :
var list = new ArrayList<>();
Няма ниHowва информация за типа на елементите, съхранявани в колекцията, а типът на колекцията ще бъде ArrayList < Object >.
4. Двойни фигурни скоби
Помните ли бързата инициализация на масива?
Току-що изброихме стойности във фигурни скоби, като това:
Примери |
---|
|
|
Създателите на Java харесаха идеята за използване на къдрави скоби за опростяване на писането на елементи на масив. Но Howво да кажем за колекциите?
Създателите на Java имаха достатъчно креативно мислене и за колекциите, което им позволи да използват трик с двойни фигурни скоби.
Със захар | Без захар |
---|---|
|
|
Ако компилаторът срещне code като в примера отляво, той го преобразува в codeа отдясно.
Кодът не става много по-компактен. Спестяванията тук са сравнително незначителни: не е нужно да пишете list
всеки път. Това може да бъде полезно, ако името на променливата е много дълго.
Но ако попаднете на code като този в проект, не се изненадвайте 🙂
GO TO FULL VERSION