Static import i Java 1.5

En ny importkonstruktion i Java 1.5 gör det möjligt att importera statiska variabler och metoder. Sen kan man använda dem utan att tala om vilken klass de finns i. Man kan till exempel importera den statiska variabeln PI och den statiska metoden cos från klassen Math på det här sättet:

import static java.lang.Math.PI;
import static java.lang.Math.cos;

Då går det alltså att komma åt värdet på PI och anropa cos utan att tala om vilken klass de kommer från:

x = cos(PI);

Utan statisk import ser samma uttryck ut så här:

x = Math.cos(Math.PI);

Det går att importera alla statiska saker från en klass med en asterisk, ungefär som när man importerar allt i ett paket med en asterisk. Man kan alltså ersätta två import-satserna i exemplet ovan med en enda:

import static java.lang.Math.*;

Ja, det var väl det viktigaste att veta om statisk import. En sak till som kan vara bra att veta är att enum-konstanter räknas som statiska (läs om enum i Java 1.5 här). Därför kan man göra så här:

import static java.math.RoundingMode.*;

RoundingMode jensAvrundningsprincip = UP;
RoundingMode bossesAvrundningsprincip = DOWN;
RoundingMode göransAvrundningsprincip = RoundingMode.DOWN;  // Tillåtet, men onödigt

RoundingMode är en enum som innehåller några olika principer för avrundning. Det går alltså att använda UP och DOWN som är element i RoundingMode, utan att ange varifrån de kommer.

Åsikter och slutsats

Ibland kan det kanske vara praktiskt att importera statiska saker, men inte speciellt ofta. Och inte känns det speciellt viktigt, ens där det är praktiskt. Varför har Sun egentligen lagt till statisk import till Java? De menar att det var nödvändigt för att få programmerare att sluta använda vad som kallas the Constant Interface Antipattern, ett sätt att programmera som är så dumt att det fått ett speciellt namn. Det är tydligen ett stort problem att folk lägger statiska variabler i ett interface för att sedan implementera interfacet i de klasser där variablerna ska användas. Och detta strider mot god programmeringsstil. Jag har svårt att tro att den bästa lösningen på problemet är att ge dessa programmerare en ny språkkonstruktion att missbruka.

Det största problemet som jag ser med statisk import är att det gör programkoden svårare att läsa. Förut var det lätt att veta varifrån en metod kom. Om det inte stod något angivet framför den så kom den från den egna klassen, eller någon av dess superklasser. Nu med statisk import i språket måste man titta efter om några sådana importeringar gjorts innan man kan veta varifrån en metod kommer. Detsamma gäller förstås även variabler.

Sun rekommenderar att använda statisk import mycket sparsamt. Min rekommendation är enklare: använd inte statisk import alls. Det är ingen större mening med det. Kanske blir koden i vissa fall lite trevligare att läsa, men det uppvägs av att det blir svårare att veta varifrån variabler och metoder kommer. Dessutom kan läsare av koden bli förvirrade eftersom statisk import är en mycket ovanlig konstruktion. Jag tycker det skulle vara bäst om statisk import inte fanns. Egentligen vill jag att du försöker glömma att du läst den här artikeln. Seså, glöm!