To úvodní zkracování s Integer je zajímavé, ale dá se pokračovat až na Integer.toString(1), což je konečně postup, který se (snad normálně) používá :-)
Ten switch nad řetězci se mi pořád nelíbí – jediná výhoda proti jiným konstrukcím je výpočet hashe už v době kompilace, ale za cenu toho, že budu mít v kódu náhodně roztroušenou sadu řetězců (která se v Javě jinak vyjadřuje enumem).
Výhoda switche s řetězci je třeba v tom, že se to pěkně píše, je to přehledné atd. To, jestli je někde pár bytů navíc 99% lidí nezajímá (třeba celý OKsystem , když vzpomenu na všechny ty JBossy, ejb 3.0 a VVA a podobný generátor gigabytů zaplácané paměti :-)), 90% z toho zbylého procenta nepíše v javě a ta zbylá 0,1 procenta to samozřejmě nebude používat.
Pěkně se to píše, ale špatně se to pak čte nebo opravuje. Máte řetězce různě roztroušené po zdrojáku, upravíte ho na jednom místě a jinde zůstane neopravený… Když to chcete udělat správně, uděláte z těch řetězců konstanty; pak zjistíte, že je to vlastně uzavřená množina a mělo by někde být uvedeno, co do té množiny patří – tak z těch konstant ještě uděláte pole nebo kolekci. A ejhle, právě jste vynalezl enum.
Zakazat je silne slovo, ale ja jakozto radikalni cistic si myslim, ze kdo potrebuje switch dela neco spatne (coz neznamena, ze se mi to samotnemu nestalo :-) ). Kdyz uz se podle nejake hodnoty switchuje, tak to je vetsinou vickrat (beztak bude nekdo chtit pocet svatku v danem mesici...) a pak uz to vede na nejake pole nebo enumy a zrovna v jave se mi reseni enumama libi mnohem vic. Napr. je to vice bezpecne pri zavadeni nove polozky.
V objektově orientovaných jazycích by se switch v podstatě nemusel a také neměl používat vůbec. Místo něj se má používat polymorfismus.
Např. Smalltalk sice switch má ve formě zprávy caseOf:otherwise:, která se od obyčejných zpráv liší tím, že (podobně jako třeba pro ifTrue:) se pro ni generuje optimalizovaný bytekód se skoky, ale v celém Pharu je použita jen jednou a to ještě v podstatě zbytečně.
switch za výraz jazyka, něco ve smyslu:
if (...) {} if (...) {} else {} switch (...) {} if (...) {} elseif (...) {} else {} A také to tak důsledně používám.
Nemyslím si, že bych byl nějak v OOP slabší.
Samozrejme ze se neda rict, ze kdo pouziva switch, tak je slabsi v OOP. Ale kdyz se podivate na typicke vyskyty, tak bud je pouzit jako mapa (klic -> hodnota) nebo jako nahrada polymorfismu. Z pocatku to vypada trivialne a nevinne, ale kdyz pak mate 20 funkci, v kazde je switch podle toho sameho klice a je to rozstrkano po celym programu, tak je na prusvih zadelano.
Ja mam takovou zkusenost, ze to nebezpecne casto diverguje timto smerem, takze misto "dusledne pouzivam" radsi rikam - kdyz pisu druhy switch dle stejneho klice, tak je na case zavest tridy, enumy nebo mapu (klic->datova struktura). Az budete muset pridat dalsi case, tak to ocenite.
Tak samozřejmě pro interní reprezentaci konstant je lepší použít enum, o tom žádná. Ale v případě třeba parsování nějakých command file (nějaké xml, csv, atd.), kde se podle elementu/prvního sloupce rozhoduje, co se bude vlastně dělat, je to skoro ideální. (ještě ideálnější by byl hash string: handling-metoda, ale občas kanón na vrabce).
V tomto směru nebyl příklad z článku zvolen úplně nejlíp, ale na druhé straně lepší, než na třech stranách definovat umělý příklad a pak dole ukázat to kouzlo JDK 7 :)
I ve vámi uvedených případech máte pořád omezenou množinu řetězců, na které program umí reagovat. Když budete chtít vypsat uživateli hlášku, že má v CSV neznámý typ sloupce a podporované jsou jen sloupce a, b, c, potřebujete jejich seznam. Když budete chtít kód testovat, zase potřebujete seznam.
Já si dovedu představit spoustu příkladů využití switche přes řetězce, ale všechny jsou takové, že když to budu chtít napsat aspoň trochu „správně“ a udržovatelně, musím to stejně změnit na enum. Proto to podle mne do Javy nepatří – jsou jazyky, kde je to plně na odpovědnosti programátora, a když si chce programátor prostřelit koleno, jazyk mu k tomu ochotně poskytne nástroj. Java je ale jiná (a často se jí to vytýká) a pokouší se takovéhle postupy programátorovi co nejvíce znepříjemnit. A teď najednou povolí takovouhle věc.