class SomeEnum {
const TYPE_A = 1;
const TYPE_B = 2;
const TYPE_C = 3;
private function __construct() {}
public static function enum() {
$rf = new ReflectionClass(__CLASS__);
return $rf->getConstants();
}
}
class SomeEnum {
const TYPE_A = 1;
const TYPE_B = 2;
const TYPE_C = 3;
private function __construct() {}
public static function enum() {
$rf = new ReflectionClass(__CLASS__);
return $rf->getConstants();
}
}
Není to typově zabezpečitelné, ale je to asi nejlepší z uvedených řešení.
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::$high)) {
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.
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)
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í.
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.
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á.
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.
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,oblí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 ...
Vazane na zemi a jeste se v case meni zarazeni do danove skupiny a velikost dane.