Tak DOPRČIC, přece nebudeš mít v konstruktoru třídy parametr BufferedWriter jenom proto, abys to potom mohl otestovat? To je úplná kravina, porušuje to zapouzdřenost, vystavuješ ven vnitřnosti třídy. Prostě uděláš to, že bufferedWriter reflexí namockuješ!
Celou dobu jsem mel podezreni na to, zes jeste neobjevil DI a IoC a tady tim jsi mi to potvrdil.
Jak uz tu psali jini, konstruktor by mel objekt inicializovat do konzistentniho stavu, jestli se pritom ma pouzit vypocet nebo jen nastavit hodnoty je podruzna zalezitost.
Tvuj problem patrne tkvi v tom, ze se ti v konstruktoru zacne objevovat komplexni logika a tim padem se ti narusi dobry zvyk, ze kazda metoda (konstruktor v tomto pripade lze chapat taky jako metodu) dela pouze jednu vec.
Jedno reseni je pouzit statickou (factory) metodu.
Ja si myslim, ze v tvem pripade by bylo jeste zahodno zvazit pristup oznacovany jako
dependency injection, kde vsechny slozitejsi objekty, ktere v konstruktoru vytvaris, se vytvori vne a pak je vlozis pomoci konstruktoru. Prinos je troji: kod bude jednodussi, testovatelnejsi a pruznejsi.
Tak DOPRČIC, přece nebudeš mít v konstruktoru třídy parametr BufferedWriter jenom proto, abys to potom mohl otestovat?
Ale takhle se to bezne dela. Akorat neuvadis nazev souboru, ale obecny writer.
Misto
private zapisSpecialneDoSouboru(String info) {pouzijes
private zapis(Writer wr) {Jednou jako writer predas FileWriter pro zapis do souboru. Jindy predas StringWriter pro zapis do bufferu, ktery pouzijes pro testovani. A pokud prijde zakaznik s nejakym uchylnym pozadavkem, muzes tam dat Writer, ktery bude posilat data po siti nebo zapisovat libovolnym zpusobem.
To je úplná kravina, porušuje to zapouzdřenost, vystavuješ ven vnitřnosti třídy.
Zadne vnirtnosti tridy nevystavujes, takze zapouzdrenost je neporusena. To paradoxne delas s tou reflexi.
Prostě uděláš to, že bufferedWriter reflexí namockuješ!
To je neskutecna prasarna.
120 Odpovědí
20755 Zhlédnutí