Komentáře k článku

Datový typ ENUM v PHP

Enum, enumerated nebo česky výčtový typ je datový typ, jehož použití na správném místě nám může pomoci zjednodušit návrh aplikace a učinit ho elegantnějším. Výčtové typy slouží k definici skupin předem známých hodnot a umožnění následné typové kontroly (Rudolf Pecinovský – Návrhové vzory). Výhody výčtového typu můžeme využívat i v návrhu PHP aplikace, pokud překonáme jisté obtíže s implementací.

Zpět na článek

13 komentářů k článku Datový typ ENUM v PHP:

  1. isnotgood

    a nestaci proste neco takovyho?

    class SomeEnum {

    const TYPE_A = 1;
    const TYPE_B = 2;
    const TYPE_C = 3;

    private function __construct() {}

    public static function enum() {
    $rf = new ReflectionClas­s(__CLASS__);
    return $rf->getConstants();
    }
    }

    1. pepca

      Re: a nestaci proste neco takovyho?

      Není to typově zabezpečitelné, ale je to asi nejlepší z uvedených řešení.

  2. aTan

    asi preklep

    nema byt v

    17.public static function getLowLevel() {
    18.if (!isset(self::$low)) {
    19.self::$zero = new self(‘low’);
    20.}
    21.return self::$low;
    22.}
    23.
    24.public static function getHighLevel() {
    25.if (!isset(self::$hig­h)) {
    26.self::$zero = new self(‘high’);
    27.}
    28.return self::$high;
    29.}

    misto self::$zero = new… spis self::$low nebo high podle metody? nejak mi to jinak nedava smysl. vracime neco cemu nikde nebylo prirazena hodnota.

  3. Jan Prachař

    Alternativa

    Já to dělam nějak takhle:

    class Enum
    {
       private static $items;
       private static $frozen;
    
       public static function add($key, Enum $item)
       {
           $class = get_called_class();
           if (!self:$frozen[$class]) {
               self::$items[$class][$key] = $value;
           } else {
               throw new Exception;
           }
    
       }
    
       public static function get($key)
       {
           $class = get_called_class();
           return self::$items[$class][$key];
       }
    
       public static function freeze()
       {
           static::$frozen = TRUE;
       }
    }
    
    class VatLevel extends Enum
    {
       const LOW = 1;
       const HIGH = 2;
    
       public $level;
       public $name;
       public $rate;
    
       public __construct($level, $name, $rate)
       {
           $this->level = $level;
           $this->name = $name;
           $this->rate = $rate;
       }
    }
    
    
    VatLevel::add(VatLevel::LOW, new VatLevel(VatLevel::LOW, 'Low', 14));
    VatLevel::add(VatLevel::HIGH, new VatLevel(VatLevel::HIGH, 'High', 20));
    VatLevel::freeze();

    K jednotlivým hodnotám se pak dostanu:

    VatLevel::get(VatLevel::LOW); //returns VatLevel(VatLevel::LOW, 'Low', 14)
  4. Gwyn

    nedokončené řešení

    Celé řešení mi přijde nedokončené. Za prvé je na první pohled vidět, že řešení obsahuje chyby v metodách getLowLevel, a getHighLevel

    Dále třída nikde neumožnuje nastavit atribut $tax.
    Autor zmiňuje, že dále ukáže možnost uložení hodnot z databáze, namísto toho se věnuje hanění jiných řešení.

  5. Oldisy3

    to srovnani s c

    to mi dost nesedi. v c proste tam kde potrebujete deklarujete promenou typu enum, a vycet mate definovanej nekde pred tim. Enum je proste jenom pro to aby sme v kodu nemuseli cist porovnani s konstantama ktere nemaji zadnou vypovidaci hodnotu, nenesou pro programatora informaci o tom, ceho se tykaji. V php mi prijde dostatecne reseni s tridou a constantami. Ze to neni typove bezpecne, to je holt vlastnost php, vymyslet proti tomu ochranu je jako boj s vetrnymi mlyny. Vymyslet prekomplikovane reseni abych si usetril jedno rovnitko navic…
    Dale pak priklad s davonou skupinou mi prijde jako krajne nevhodny, toto je polo abstraktni reseni michajici staticky a dynamicky pristup, nemuzu se spolehnout na to ze jsou momentalne danove skupiny dve nebo tri, a ze jich nebude brzo napriklad pet. Na danovou skupinu se hodi spise kontejner a nebo mapa, tedy par klic => hodnota.
    Pekny priklad na enum je napriklad karetni hra a respektive typ karty, kde je mnozstvi a typy hodnot dane a nemenne.

  6. beny

    Ukládání sazeb DPH

    Dovolím si trošku nesouhlasit s ukládáním hodnoty DPH, resp. ukládáním reference. Pokud děláte např. nějaký skladový systém, musíte ukládat i nákupní ceny a nákupní sazbu DPH. A ta se v čase mění. Např. výrobek XY byl loni nakoupen s DPH 10%, no a letos byl zakoupen se 14%. Vzhledem k účetnictví ale nemůžete ve skladu přepočítat nákupny, pouze prodejky. Takže buď si ukládáte hodnotu DPH nákupky, anebo referenci na správnou hodnotu DPH, ale platnou v době naskladnění zboží -> číselník DPH s platností a časem. Není to taková trivka, jak to na první pohled vypadá.

  7. JakubTesarek

    reakce

    Dobrý večer,
    v první řadě bych vám chtěl poděkovat za přínosné komentáře.
    Pokusím se reagovat na vaše dotazy a připomínky.

    Příklad s DPH jsem vybral proto, abych ukázal, že díky objektové implementaci je možné prvky výčtu využít i praktickým způsobem a nejedná se jen o nějaké vymýšlení složitostí. Pracuji jako programátor v mezinárodní (a jedné z největších českých) společností se specializací na výrobu e-shopů. Samozřejmě že problém s DPH je trochu složitější. Dokonce je tam i problém s DPH, kdy se udělá objednávka před změnou, ale faktura se vystavuje až po změně DPH. Pokud máte skladový systém zavedený pomocí příjemek a výdejek, tak tento problém se dá velmi elegantně moji třídou řešit. Daňové zařazení položky se totiž (narozdíl od výše daně) mění pouze minimálně. A já přiznávám, že jsem toto řešení napsal až po našem vstupu do EU. To už jsem, ale myslím trochu OT. Rád si o tom popovídám, ale sem se to nehodí.

    Děkuji za postřeh, že článek vypadá nedokončeně. Původně měl skutečně jinou koncepci. Jedná se o první článek, který jsem pro zdroják psal a tak jsme se s redakcí dohodli, že bych mu dal trochu jinou podobu. Ze stejného důvodu jsem nakonec do článku umístil i komentáře k implementacím, na kterých jsme se shodli, že by bylo dobré na ně reagovat. Mým cílem rozhodně nebylo očerňovat jiná řešení. Spíše jsem chtěl ukázat, že nejsem první, kdo podobný problém řeší. Poukázal jsem na důvody, proč bych já nemohl tato řešení použít a jak jsem se je snažil vyřešit ve svém kódu.

    Za přiložené kódy děkuji, určitě se na ně podívám. Chyby zreviduji, pokud tam jsou, pak se velmi omlouvám. Pokud budu psát další článek, slibuji, že si dám větší pozor.

    1. Gekon

      Re: reakce

      Celé to řešení mi přijde totálně nešťastné …
      Osobně mám tabulku vat, kde se definuje koeficient – 0.2,0.05 … (V reálu je to složitější, je to vázané na zemi. toto pro jednoduchost stačí)

      Druhá tabulka se zbožím, kde se odkazuje na pk z VAT tabulky (ať žijí cizí klíče)

      Tím není potřebná (prakticky) žádná obslužná logika, protože si to cizí klíč ohlídá. Sice se při vypisování zboží musí joinovat tabulka VAT, ale co si budeme povídat, stejně se jich joinuje hodně (sklady,tagy,o­blíbené produkty …)

      Vystačím si s klasickým selectem z VAT tabulky a s update,insertem do tabulky se zbožím, kde si jen hlídám chyby fk.

      Osobně mi tento článek připomíná laborku na zítřek, na kterou jsem si vzpoměl ve tři ráno …

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3588