Java a statické metody

[Filip Jirsák]

Ano, to může nastat, nicméně jsou i situace, kde to nastat nemusí a kde je velmi nepravděpodobné, že bude třeba implementaci nahradit. V takových situacích je IMO lepší myslet na jednoduchost a přehlednost kódu - tj. klidně zvolit jednu pevnou implementaci.

Podle mne jednoduchost a přehlednost znamená, že pro stejnou věc používám jeden postup – ne že musím pokaždé přemýšlet, zda to v tomhle konkrétním případě ještě má být třída se statickými metodami, nebo už závislost nastavovaná z venku. Navíc už jsem viděl tolik případů, kdy si někdo myslel, že je to velmi nepravděpodobné, a pak se to muselo nějak hackovat... Jinak to ,,nepravděpodobné, že bude potřeba implementaci nahradit" taky dost často znamená ,,nepravděpodobné, že by to někdo chtěl testovat unit testy". Protože když máte v kódu tvrdou závislost na nějaké implementaci, můžete otestovat jen obojí najednou (váš kód spolu s tou implementací), pak už to není tak docela jednotkový test, no a komplexní testy se zase o poznání hůř píšou a udržují.

[Reklama]

[Ondra Satai Nekola]

Pokud chces praci, kde neni potreba myslet, tak programovani neni dobra volba. Ne ze by bylo potreba vzdycky znova vynalezat kolo, ale na druhou stranu - vazne je potreba jeden ze zakladnich prostredku jazyka odmitat jenom protoze jsi linej se zamyslet?

A samozrejme nahrazovani implementace nesouvisi s testovanim te veci unittesty, ale to je pocitam jenom spatna formulace a myslel jsi mockovani pri testech jinych veci?

[Filip Jirsák]

vazne je potreba jeden ze zakladnich prostredku jazyka odmitat jenom protoze jsi linej se zamyslet?

Já statické metody neodmítám, napsal jsem myslím docela jasně, kdy je podle mne vhodné je použít. Jinak projevem nepřemýšlení je právě to zneužívání statických metod i tam, kde by měla být volná vazba.

A samozrejme nahrazovani implementace nesouvisi s testovanim te veci unittesty, ale to je pocitam jenom spatna formulace a myslel jsi mockovani pri testech jinych veci?

Jenže bez mockování nedokážete otestovat jenom tu jednu komponentu – nanejvýš otestujete komponentu a vše, na čem závisí.

[JSH]

Já statické metody neodmítám, napsal jsem myslím docela jasně, kdy je podle mne vhodné je použít. Jinak projevem nepřemýšlení je právě to zneužívání statických metod i tam, kde by měla být volná vazba.

Pokud navrhujete volnou vazbu i pro goniometrické funkce, tak už opravdu netuším, kde by by bylo vhodné použít statické metody.

Jenže bez mockování nedokážete otestovat jenom tu jednu komponentu – nanejvýš otestujete komponentu a vše, na čem závisí.

Napřed se otestují závislosti a pak komponenta i se závislostmi? Proč by tohle neměl být unittest? Přece nebudu omezovat unittesty jen na věci, které mají mockovatelné závislosti.

[Filip Jirsák]

Napřed se otestují závislosti a pak komponenta i se závislostmi? Proč by tohle neměl být unittest?

Není to jednotkový test (unit test), protože netestuje jednotku, ale několik jednotek (komponenta a její závislosti). Takové testy také mají smysl, ale jsou komplexnější. A moc pro ně neexistuje nějaká rozšířená podpora, často se k tomu ohýbají nástroje pro jednotkové testy (v Javě JUnit nebo TestNG), ale to nefunguje úplně ideálně. Pak vám třeba při chybě v té závislosti padají i testy závislé komponenty, což je špatně (komponenta je v pořádku ale padá její test – to je chyba).

Přece nebudu omezovat unittesty jen na věci, které mají mockovatelné závislosti.

Je to naopak, abyste mohl dobře testovat pomocí jednotkových testů, potřebujete mockovatelné závislosti. Samozřejmě, naprasit jde ledacos a také se to děje, ale to už se pak nebavíme o best practices.

[Reklama]

[Natix]

https://taskinoor.wordpress.com/2011/09/21/the-abuse-of-design-patterns-in-writing-a-hello-world-program/

[Kit]

Já statické metody neodmítám, napsal jsem myslím docela jasně, kdy je podle mne vhodné je použít. Jinak projevem nepřemýšlení je právě to zneužívání statických metod i tam, kde by měla být volná vazba.

Pokud navrhujete volnou vazbu i pro goniometrické funkce, tak už opravdu netuším, kde by by bylo vhodné použít statické metody.

Volnou vazbu na sinus zde navrhl nějaký příznivce statických metod, aby zjistil, kam až je Filip ochoten zajít. A Filip na to kývl. Proč ne? Pokud dělám program na kalkulačku s goniometrickými funkcemi, tak by se mi tato vazba hodila pro injektáž volané funkce. Jenže je statická a proto ji musím kvůli tomu zbytečně obalovat do dalšího objektu. Také by se mi do ní hodila funkce sin(), která pracuje s úhlovými stupni místo radiánů tak, abych si mohl nějakým radiobuttonem deg/rad/grad za běhu přepínat příslušnou knihovnu.

Jenže bez mockování nedokážete otestovat jenom tu jednu komponentu – nanejvýš otestujete komponentu a vše, na čem závisí.

Napřed se otestují závislosti a pak komponenta i se závislostmi? Proč by tohle neměl být unittest? Přece nebudu omezovat unittesty jen na věci, které mají mockovatelné závislosti.

Už jsem viděl dotaz, "proč někomu sin(30) nevrací 0.5". Kdyby si dotyčný napsal test na tuto knihovní funkci, jistě by poznal proč. Obráceně jsou případy, kdy si místo funkce sin() chci namockovat jinou hodnotu, např. 1.5 nebo -4.5, abych si zjistil odolnost navazující jednotky na nesmyslné hodnoty. Bez možnosti mockování by to vůbec nešlo, protože takové hodnoty z funkce sin() nedostanu.

[F.]

Napřed se otestují závislosti a pak komponenta i se závislostmi? Proč by tohle neměl být unittest?

Není to jednotkový test (unit test), protože netestuje jednotku, ale několik jednotek (komponenta a její závislosti). Takové testy také mají smysl, ale jsou komplexnější. A moc pro ně neexistuje nějaká rozšířená podpora, často se k tomu ohýbají nástroje pro jednotkové testy (v Javě JUnit nebo TestNG), ale to nefunguje úplně ideálně. Pak vám třeba při chybě v té závislosti padají i testy závislé komponenty, což je špatně (komponenta je v pořádku ale padá její test – to je chyba).

Přece nebudu omezovat unittesty jen na věci, které mají mockovatelné závislosti.

Je to naopak, abyste mohl dobře testovat pomocí jednotkových testů, potřebujete mockovatelné závislosti. Samozřejmě, naprasit jde ledacos a také se to děje, ale to už se pak nebavíme o best practices.

To jste se dostali k classical and mockist testing, nelze obecne rict ze jedno je lepsi/horsi, dobre/spatne.

http://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting

[Ondra Satai Nekola]

Volnou vazbu na sinus zde navrhl nějaký příznivce statických metod, aby zjistil, kam až je Filip ochoten zajít. A Filip na to kývl. Proč ne? Pokud dělám program na kalkulačku s goniometrickými funkcemi, tak by se mi tato vazba hodila pro injektáž volané funkce. Jenže je statická a proto ji musím kvůli tomu zbytečně obalovat do dalšího objektu. Také by se mi do ní hodila funkce sin(), která pracuje s úhlovými stupni místo radiánů tak, abych si mohl nějakým radiobuttonem deg/rad/grad za běhu přepínat příslušnou knihovnu.

Ale to uz jsou dve uplne jina zadani. Nemluve o tom, ze zadne baleni objektu ani tak nepotrebujes, pokud mas first class funkce.

Už jsem viděl dotaz, "proč někomu sin(30) nevrací 0.5". Kdyby si dotyčný napsal test na tuto knihovní funkci, jistě by poznal proč. Obráceně jsou případy, kdy si místo funkce sin() chci namockovat jinou hodnotu, např. 1.5 nebo -4.5, abych si zjistil odolnost navazující jednotky na nesmyslné hodnoty. Bez možnosti mockování by to vůbec nešlo, protože takové hodnoty z funkce sin() nedostanu.

Bud tam mas volnou vazbu a pak ma smysl to testovat a muzes to testovat.
Nebo nemas. Pak zase tu vadnou hodnotu dostat ze "sinu" nemuzes a resis imaginarni problem.

[Filip Jirsák]

Bud tam mas volnou vazbu a pak ma smysl to testovat a muzes to testovat.
Nebo nemas. Pak zase tu vadnou hodnotu dostat ze "sinu" nemuzes a resis imaginarni problem.

Kdybych měl pětikorunu za všechny tyhle ,,nemůžeš", u kterých se později ukázalo, že ,,můžeš", byl bych nejbohatší člověk na světě. To, že jste z vámi používané implementace v současné verzi chybu nevyloudil, neznamená, že se to nemůže stát. Spustíte to na jiném JRE nebo jenom na jiné verzi téhož JRE, a pak to vysvětlujte té výjimce, že tam nemůže vypadnout.

[Radek Miček]

Bud tam mas volnou vazbu a pak ma smysl to testovat a muzes to testovat.
Nebo nemas. Pak zase tu vadnou hodnotu dostat ze "sinu" nemuzes a resis imaginarni problem.

Kdybych měl pětikorunu za všechny tyhle ,,nemůžeš", u kterých se později ukázalo, že ,,můžeš", byl bych nejbohatší člověk na světě. To, že jste z vámi používané implementace v současné verzi chybu nevyloudil, neznamená, že se to nemůže stát. Spustíte to na jiném JRE nebo jenom na jiné verzi téhož JRE, a pak to vysvětlujte té výjimce, že tam nemůže vypadnout.

Používání standardních typů jako například String nebo int vám nevadí?

[Ondra Satai Nekola]

Bud tam mas volnou vazbu a pak ma smysl to testovat a muzes to testovat.
Nebo nemas. Pak zase tu vadnou hodnotu dostat ze "sinu" nemuzes a resis imaginarni problem.

Kdybych měl pětikorunu za všechny tyhle ,,nemůžeš", u kterých se později ukázalo, že ,,můžeš", byl bych nejbohatší člověk na světě. To, že jste z vámi používané implementace v současné verzi chybu nevyloudil, neznamená, že se to nemůže stát. Spustíte to na jiném JRE nebo jenom na jiné verzi téhož JRE, a pak to vysvětlujte té výjimce, že tam nemůže vypadnout.

Takovehle starosti bych fakt chtel mit (nebo asi ne, problemy s overengineeringem jsou pak peklo). Ale kdyz to uz resis, tak stare dobre pravidlo stimulate, don't simulate.

[Ondra Satai Nekola]

Ale hlavne nam tu jeste (a opet) dluzis odpovedi, jak bys ve svem fundamentalistickem svete resil nektere celkem bezne problemy.

[Filip Jirsák]

problemy s overengineeringem jsou pak peklo

Co je pekelného na tom, že místo

Kód [Vybrat] Rozbalit


Transformer.transform(...);


napíšete

Kód [Vybrat] Rozbalit


private final Transformer transformer;

public X(Transformer transformer) {
  this.transformer = transformer;
}

transformer.transform(...);


?

[JSH]

Co je pekelného ...

Třeba že je najednou ten Transformer součástí rozhraní i když by nemusel? Někdy je to ok, ale na to aby to byla obecná best-practice je tam až moc podmínek.