1. Syntactische suiker
Programmeurs houden ervan wanneer een complexe code of logica in een paar regels kan worden geschreven, waardoor code compact en leesbaar wordt. En de makers van programmeertalen helpen daar soms bij.
Een gelikte taalfunctie waarmee je een kortere weg kunt nemen (minder code schrijven) wordt syntactische suiker genoemd . Maar om eerlijk te zijn, er is er heel weinig van op Java.
De makers van Java hebben er alles aan gedaan om redundantie in Java te elimineren. Als je met C++ iets op 20 manieren kunt doen, dan kun je het met Java maar op één manier doen.
Maar noch Java-programmeurs, noch de makers van Java hielden van het gebrek aan vrijheid. En soms maakt suiker het leven gemakkelijker voor gewone mensen zoals jij en ik.
Trouwens, je bent al wat syntactische suiker tegengekomen: autoboxing en unboxing . Laten we vergelijken:
Lange code | Compacte code |
---|---|
|
|
|
|
|
|
In plaats van de lange code zoals aan de linkerkant, kun je de compactere code aan de rechterkant schrijven. En een intelligente Java-compiler genereert de uitgebreide versie van de code op basis van de korte versie van de code. Dit is precies wat syntactische suiker is.
2. Inferentie van het type van een variabele: het var
sleutelwoord
In Java 11 is de compiler nog slimmer geworden en kan nu het type van een gedeclareerde variabele bepalen op basis van het type waarde dat eraan is toegewezen . In code ziet het er zo uit:
var name = value;
Waar name
is de naam van een nieuwe variabele, waarde is de beginwaarde en var
is een sleutelwoord dat wordt gebruikt om de variabele te declareren. Het type van de naamvariabele is hetzelfde als het type waarde dat eraan is toegewezen.
Voorbeelden:
Hoe we de code zien | Wat de compiler ziet |
---|---|
|
|
|
|
|
|
|
|
|
|
De compiler bepaalt zelf het type van de variabele of leidt dit af op basis van de waarde die eraan is toegewezen.
Programmeurs debatteerden fel over het al dan niet toevoegen van een dergelijke functie aan de taal. Veel mensen vreesden dat var
misbruik zou worden gemaakt en dat de leesbaarheid van de code daardoor zou afnemen.
Hier zit een kern van waarheid in, dus het is het beste om te gebruiken var
waar het de leesbaarheid van de code vergroot. Deze bijvoorbeeld in twee gevallen:
Geval 1: kijkend naar de waarde die aan de variabele is toegekend, is het type van de variabele meteen duidelijk
Code | Uitleg |
---|---|
|
De variabele is eenInputStream |
|
De variabele is eenString |
In deze gevallen mag u geen var
. Wat is het type van de variabele?
Code | Uitleg |
---|---|
|
Het is moeilijk om het type van de variabele te bepalen |
|
Het is moeilijk om het type van de variabele te bepalen |
Geval 2: het type van de variabele is niet belangrijk voor het begrijpen van de code
Code hoeft vaak geen methodes op een variabele aan te roepen, bijvoorbeeld wanneer een variabele gewoon wordt gebruikt om tijdelijk iets op te slaan. In dit geval var
vermindert het gebruik zeker niet de leesbaarheid van de code:
Lange code | Compacte code |
---|---|
|
We hebben metadata van de stream stream gehaald en opgeslagen in de storage repository. Het data specifieke type van de variabele is niet belangrijk. |
De gulden middenweg
Nu geef ik drie manieren om dezelfde code te schrijven. Gebruiken var
zou de beste optie zijn.
Code | Opmerking |
---|---|
|
Te compact |
|
Precies goed |
|
Te gedetailleerd |
Door van de versie met 1 regel naar de versie met 2 regels te gaan, hebben we de code iets leesbaarder gemaakt door een variabelenaam ( headerInfo
) te gebruiken. Nu is het duidelijk dat de methode niet alleen meta-informatie retourneert, maar ook header-informatie.
De derde versie is overdreven uitgebreid. Dat headerInfo
het a is FileMetaInfo
blijkt al vrij duidelijk uit de getFileMetaInfo()
methode. Het doel van de meta-informatie is veel interessanter.
3. Type weglaten met de diamantoperator:<>
Zelfs voordat de var
operator verscheen, waren er pogingen om de compiler te leren verzamelingstypen af te leiden. U zult het ermee eens zijn dat deze notatie een beetje overbodig lijkt:
ArrayList<String> list = new ArrayList<String>();
Vanaf de zevende versie van Java kon je bij het schrijven van een verzamelingstype het type van de verzamelingselementen weglaten als dit was opgegeven bij het declareren van een variabele. Met andere woorden, de bovenstaande code kan in een enigszins verkorte vorm worden geschreven:
ArrayList<String> list = new ArrayList<>();
Zoals u kunt zien, hoeft u String niet langer een tweede keer te schrijven. Niet zo cool als bij de var-operator, maar het leek op dat moment vooruitgang.
De lege punthaken in het verzamelingstype werden de diamantoperator genoemd , omdat de twee punthaken vaag op een diamant lijken.
Het is onwenselijk om het var
trefwoord en de diamantoperator tegelijkertijd te gebruiken :
var list = new ArrayList<>();
Er is helemaal geen informatie over het type elementen dat in de verzameling is opgeslagen en het verzamelingstype is ArrayList < Object >.
4. Dubbele accolades
Herinner je je snelle array-initialisatie?
We hebben zojuist waarden tussen accolades weergegeven, zoals deze:
Voorbeelden |
---|
|
|
De makers van Java hielden van het idee om accolades te gebruiken om het schrijven van elementen van een array te vereenvoudigen. Maar hoe zit het met collecties?
De makers van Java hadden ook genoeg creatief denkvermogen voor collecties, waardoor ze een trucje met dubbele accolades konden gebruiken.
Met suiker | Zonder suiker |
---|---|
|
|
Als de compiler code tegenkomt zoals in het voorbeeld aan de linkerkant, dan converteert hij deze naar de code aan de rechterkant.
Veel compacter wordt de code niet. De besparingen zijn hier vrij onbeduidend: u hoeft niet list
elke keer te schrijven. Dit kan handig zijn als de naam van de variabele erg lang is.
Maar als je dergelijke code tegenkomt in een project, wees dan niet verbaasd 🙂
GO TO FULL VERSION