Pokus jak odstranit ContainerFactory

[tacoberu]

Je to jen nástřel, jak by takové řešení mohlo vypadat. Je asi zřejmé, že jsem řešil hlavně problém, jak do toho traitu ten DIC dostat, nikoliv refaktorovat celej ContainerFactory.

[mrtnzlml]

Trošku jsem čekal, že něco takového napíšeš. Cením si snahy, ale - s tímto návrhem jsi spokojen? Možná je to podle učebnice, ale fakt bych to používat nechtěl. Dnešní ekvivalent je takový:

<?php

require __DIR__ . '/bootstrap.php';

/**
 * @testCase
 */
class HomepagePresenterTest extends Tester\TestCase
{

    use Testbench\TPresenter;

    public function testRenderDefault()
    {
        $this->checkAction('Post:Default:default');
    }

}

(new HomepagePresenterTest)->run();

A to je pro uživatele (v tomto případě programátory) markantní rozdíl. To se s tím raději já budu trápit a hledat nejlepší řešení u sebe, než abych obtěžoval jednou abstraktní metodou, která mimochodem nemá pro zbytek kódu vůbec žádný význam.

Navíc podobným stylem byl Testbench napsán v prvních verzích a utekl jsem od toho i z toho důvodu, že se takto zakládá DIC i když to není vůbec potřeba. To už by se dnes sice dalo zase zpochybnit, ale stejně.

[tacoberu]

Můžeš mi vysvětlit jak mám chápat: "abstraktní metodou, která mimochodem nemá pro zbytek kódu vůbec žádný význam"?

Jinak ano, z mého pohledu je toto řešení výrazně lepší, než stávající. Je to v mejch očích přesně ten rozdíl mezi SL a DI. Ani ne tak kůli učebnici, jako spíše z důvodů mnohem méně zajímavých, jako je ohnutelnost a čitelnost. Ten markantní rozdíl mi připománá toto. No nic :-)

[mrtnzlml]

Tvoje řešení se mi nelíbí, takže ho implementovat nebudu. Move on...

[tacoberu]

E? Nechápu! Já chtěl jen znát tvůj názor. Ani mě nenapadlo, že by si to měl implementovat...

[mrtnzlml]

Ok, tak ještě jednou a klidně. Nejvíce se mi na tom nelíbí to, že to úplně porušuje původní myšlenku toho nástroje - jednoduchost (použití i implementace). Proto, abych mohl otestovat presenter stačí jen použít traitu TPresenter a začít testovat. Proč bych měl uživatele nutit implementovat metodu getDIContainer a __construct, když ji ve skutečnosti potřebuje ta traita a to uživatele vůbec nemusí zajímat? V čem je to lepší?

[tacoberu]

Prapůvodní otázka zněla, zda má Singleton nějaké reálné použití. Ty si odkázal tento kód, tvrzením, že to z principu jinak nejde. Já ti ukázal, že to jde. Ty jsi reagoval, že je to ale ošklivější.

To je všechno.

Nemusíme se bavit o tom, komu co přijde hezčí, nebo ošklivější. To jsou tak subjektivní věci, že to nestojí za námahu.

Dle mého názoru je to lepší z důvodu flexibility a čitelnosti. Dle mého názoru (se kterým samozřejmě nemusíš souhlasit) není tak velký rozdíl mezi tím, že si tam frkne traitu a naimplementuje jednu metodu; a mezi tím, že si tam frkne traitu, a pak ještě pošteluje prostředí, protože ta traita si odněkud magicky natahuje kýho šlaka bůvíco.

Toť vše k mé argumentaci.

[mrtnzlml]

Jsi borec. Ukázal jsi mi překombinovaný kód pro dokázání pointy. Tato diskuse se točí v kruhu. Zavírám.

[mrtnzlml]

související diskuse