Diskuze: Co by jste na PHP zlepšili?
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.

Tvůrce

Zobrazeno 13 zpráv z 63.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Hmm, pěkný. Ale proč to musí být Singleton? Proč to děláš staticky, když můžeš použít
$registr = new Registry(); // vytvořím registr
$registr->klic = $object; // zapíšu do registru
echo $registr->klic; // přečtu z registru
Žádnou statiku ani Singleton nepotřebuji. Počet instancí si ve třídě ohlídám. Pokud chci zablokovat klonování, nadefinuji metodu __clone().
Protože tím ušetřím řádek vytvoření instance a dalších 4+/-
řádků při napsání __clone().
Ten řádek vytvoření instance napíšu pouze jednou v celé aplikaci. To není zrovna významná úspora. Chci přece jen jednu instanci. Podobně i __clone() se v takových případech píše na jeden řádek, ale de facto ani není potřebný.
Jak v takových případech řešíš, když Registry potřebuješ při testování nahradit stubem? Pokud to uděláš dynamicky, je to velmi jednoduché:
$registr = new RegistryStub();
a na zbytku programu nemusíš měnit ani písmenko. Pokud to uděláš staticky, je to sice proveditelné, ale můžeš si těmi editacemi tu aplikaci poškodit. Nehledě k tomu, že to strašně zdržuje.
Nechápu, proč bych měl pro testování vytvářit novou třídu? K jejímu
testování přeci můžu použít originál nehledě na to, že při registru
ani testování není potřebné, jelikož je její definice jednoduchá.
A jak říkám - tvá definice registru neřeší problém více
programátorů.
Mno, ale tohle už není předmětem diskuze.
Pokud ta třída manipuluje s databází, tak jí přece při testování nebudu dávat k dispozici ostrá data. Podstrčím jí jen stub databáze, který třeba místo provádění SQL modifikací ty dotazy loguje a při selectech dodává různé testovací výstupy, které testovaná metoda dál zpracovává.
Předmětem diskuze je, že požaduješ vlastnosti PHP, které jsou zbytečné.
Jestli třída manipuluje z databází, jednoduše nebude Singleton. Při databázových vrstvách
nevidím její využití.
Právě v souvislosti s databází vidím nejčastější chybné použití Singletonu. Kromě toho ty tvé Registry jsou de facto také databáze.
Použití Singletonu v databázích není moc výhodné, osobně používám
modely, které se připojují ke kontrolerům.
Ale jsou to dočasné databáze, a jejich data se načítají při každém
obnovení stránky. Proto je možné pracovat s ostrými daty, pokud jsou ty
data správně nastavena použitím public/private/protected, což by měla
být i tak.
Když v Registry potřebuješ při testování své třídy simulovat různá výstupní data nebo potřebuješ logovat vstup do Registry, tak to děláš jak?
Kontrolery a viewery se v MVC připojují k modelům. S databází pracuje jen model, ale i ten je potřeba otestovat.
Jak už jsem říkal - Registry má jednoduchou definici, a není třeba ji
testovat. Navíc nemá žádná výstupní data. Jednoduše zaznamenává
všechny vnitřní třídy a nastavení, které si pak rozeberou vedlejší
třídy. A vstup do Registry se může logovat jednoduše, stačí přidat
další datový člen a do něj logovat.
Kdo říkal, že mluvím o MVC?
Osobně používám MVC, ale když potřebuju, proč si nevytvořit
singlenton registr?
... osobně používám modely, které se připojují ke
kontrolerům.
Každou třídu je nutné testovat. Ty tvé Registry podle tvé definice jsou vlastně modelem. Takže žádná statika není potřebná.
Přece do Registry nebudu přidávat vlastnost, kterou nebudu potřebovat v produkci. Testy zákazník nedostane a přece je nebudu v každém vydání odmazávat.
Nepsal jsem nic o testování Registry, ale o testování tříd, které tuto třídu potřebují.
Zobrazeno 13 zpráv z 63.