A magic numberek kiemelesenek szerepe a karbantarthato kodban

Nade mi van, ha ezeket kirakjuk valami kozos valtozoba (DRY)?

--

public static final String BEACHBALL = "beachball";
public static final String VOLLEYBALL = "volleyball";


...

String typeValue = (String) paramValue.get("type");

if (BEACHBALL.equals(typeValue)) {
// do something
} else if (VOLLEYBALL.equals(typeValue)) {
// do something else
}

...

somewhereElseInTheCodebase();

if (BEACHBALL.equals(typeValue)) {
// do something
} else if (VOLLEYBALL.equals(typeValue)) {
// do something else
}

--

Mit nyertunk most, azon kivul, hogy megtanultunk egy uj shortcutot az IDE-ben? Hat, hogy kihasznaljuk a forditot es az IDE-t a kod validalasaban! Nem nekunk (vagy az utodunknak) kell kezzel melozni azert, hogy a kod ne omoljon ossze, hanem megoldja ezt helyette a fordito, mi meg fokuszalhatunk a koddal valo birkozas helyett az erdemi munkara. Nincs veletlen typo, hiszen valtozot hasznalunk, nem stringet. Refaktoralas, atnevezes hipi-szupi konnyu, akar a valtozonev, akar az ertek elnevezese valtozik.

Na de lehet am ezt meg cifrazni azzal, ha az egeszet kitesszuk enum-ba, aminek leginkabb csoportositasi/olvashatosagi szerepe van, nem beszelve arrol, hogy igy a kulonbozo ertekek mar osztalyokon ativeloen is hasznalhatoak (DRY).

--

public enum ParameterType {
BEACHBALL, VOLLEYBALL
}


...

String typeValue = (String) paramValue.get("type");
ParameterType type = ParameterType.valueOf(typeValue);

if (ParameterType.BEACHBALL.equals(type)) {
// do something
} else if (ParameterType.VOLLEYBALL.equals(type)) {
// do something else
}

...

somewhereElseInTheCodebase();

if (type.equals(ParameterType.BEACHBALL))) {
// do something
} else if (type.equals(ParameterType.VOLLEYBALL)) {
// do something else
}

--

Ezzel elertuk, hogy mar a kod elso olvasasa alatt is teljesen vilagos, hogy mi az a INTEGER es STRING amirol szo van (parameter tipus), utana is tudunk nezni, hogy az meg milyen ertekeket vehet fel, nem kell a kodbazist vegigbogaraszni.

En alapvetoen ugy vagyok ezzel, hogy szerintem ha nem is a kod irojanak a kotelessege ezeket kirakni _legalabb_ egy konstansba, de akkor annak, aki legkozelebb piszkalja a kod ezen reszet. Konstansba kirakni meg azert is nagyon jo, hiszen mint megallapitottuk, a refaktoralas egyszeru, ha segit a fordito, es sikit, ha nem mindenhol irtuk at a kodot pl. enumosra.

Aki akar kuldeni egy ekezetes valtozatot, ne kimeljen, kicserelem :)

Szerk: es meg akar az egeszet at is rakhatjuk egy switch-case-be, amivel megintcsak sokat nyerunk olvashatosag teren!

--

public enum ParameterType {
BEACHBALL, VOLLEYBALL
}


...

String typeValue = (String) paramValue.get("type");
ParameterType type = ParameterType.valueOf(typeValue);

switch (type) {
case BEACHBALL:
// do something
break;
case VOLLEYBALL:
// do something else
break;
}

...

somewhereElseInTheCodebase();

switch (type) {
case BEACHBALL:
// do something
break;
case VOLLEYBALL:
// do something else
break;
}

--

Edit: megvaltoztattam a parameter type-okat integer es string-rol beachball es volleyballra, mert nem volt egyertelmu paraknak, hogy ez most reflection, vagy honnan van az a type (a peldat egy JSON object feldolgozasabol vettem).