Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Jinak našel jsi to krásně, ale špatně. To co jsi našel je indoor.Našel jsem přesně to, o čem jsem psal. Že je to indoor a že už se to nevyrábí nevadí, protože to slouží pro inspiraci, co se také vyrábí a co se dá hledat. Navíc to, že spoj vede exteriérem, vůbec neznamená, že se na to nedá použít indoor zařízení. Ony se ty radiové vlny šíří vzduchem pořád stejně, ať jsou pod střechu nebo ne.
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.
Případně od TP-Linku nebo D-Linku existuje hotové řešení, dva panýlky proti sobě, z každého vede ethernetový kabel a je k němu PoE, nic nemusíte nastavovat. Interně to komunikuje právě na 5 GHz, na přímou viditelnost by to mohlo fungovat. Akorát to teď nedokáže rychle dohledat.Tak jsem to našel a je to nakonec také Ubiquiti, akorát už se asi nevyrábí: UBNT AirWire Indoor bridge kit 5 Ghz. Ale pro vaše potřeby to má malé antény.
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í.
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í.
V Javě (až do verze 9) například proto, že jinak vzniká propletenec závislostí, který se za chvíli těžko udržuje a spravuje. Když váš kód závisí na rozhraní, nemusí vás zajímat, že implementace bude záviset ještě ne něčem dalším. Pokud závisí na implementaci, ta nejspíš bude záviset na něčem dalším, a tím na tom tranzitivně začne záviset i váš kód. A také pak kód nejde rozumně testovat.Best practice je udělat to tak, aby se implementace dala vyměňovat
Proč myslíte?
Proč bych si jako programátor měl komplikovat život nějakou továrnou na abstraktní sinovadla.Protože to není komplikace, ale výrazné zjednodušení. Továrnu samozřejmě nebudete vymýšlet, protože na to máte framework, který vám dělá továrnu pro další desítky objektů – takže není důvod pro jeden jediný objekt to dělat jinak.
Proč bych měl vůbec chtít psát vlastní implementaci?Třeba proto, že budete mít procesor, který na to má jedinou instrukci.
Bavíme se o sinu. Pro ten mají jedinou instrukci už stařičké pentia.Existují i jiné procesory.
Takže můžu použít jednoduchou funkci, kterou mi překladač může triviální peephole optimalizací a inlinováním nahradit jedinou instrukcí.Bavíme se o Javě. Bytecode nemá instrukci pro sin.
Navíc překladači zabráním jakkoliv to volání optimalizovat páč netuší co za objekt tam pak dostane, jaké to má vedlejší efekty a podobně.V případě Javy nedělá překladač skoro žádné optimalizace, drtivou většinu jich dělá JIT. A tohle JIT v optimalizaci nijak nebrání, naopak volání virtuálních metod s pouze jednou implementací umí JIT optimalizovat docela dobře.
Coz plati pro cokoli z java.util, java.lanf, javax atd, atp.Platí to úplně pro cokoli. Pokud budete mít na classpath dvě třídy stejného jména, aplikace to sice přežije<sup>*)</sup>, ale použije je jen jedna třída a z aplikace nedokážete ovlivnit, která.
Fakt ne?Fakt ne. Zkuste si napsat svou vlastní implementaci Math.sin() a bez hackování bootclasspath docílit toho, aby ji vaši aplikace použila, když zavoláte java.lang.Math.sin().
Statická metoda může volat implementaci, jenž je uložena v nějaké statické proměnné, stačí tedy změnit tuto proměnnou.Uživatel je pak ale pořád závislý na implementaci té statické metody. Navíc ta statická proměnná je globální proměnná pro celý classloader, takže když jí jeden uživatel změní, změní implementaci všem.
Mám jednoduchou funkci sinus a její tři možné implementace z nichž jednu překladač při JIT vybere a použije.Ne, překladač JIT žádnou implementaci nevybere.
Přesně tak to pokud vím Java dělá, akorát nemá ty jednoduché funkce a musí si vypomáhat statickýma metodama.Ne, JIT žádnou implementaci nevybírá. Kdybyste použil statickou metodu, váš kód na té statické metodě bude záviset a nezměníte to jinak, než změnou zdrojového kódu. Až se za pár let stane běžnou součástí počítačů komponenta, která bude umět sinus počítat tisíckrát rychleji, váš kód bude pořád dál používat starou pomalou metodu počítání na CPU.
Proč bych tady měl chtít cokoliv jiného než tu jednoduchou funkci?Máte tři různé implementace. Pokud chcete, aby byly vzájemně zastupitelné, musí mít společné rozhraní. Uživatel té funkce používá rozhraní, nemá vazbu přímo na nějakou implementaci. No a pak samozřejmě musíte mít nějaký kód, který dosadí tu konkrétní implementaci.
interface TrigonometricFunctions {
public double sin(double angle);
}
class Calculator {
private final TrigonometricFunctions trigonometricFunctions;
public Calculator(TrigonometricFunctions trigonometricFunctions) {
assert trigonometricFunctions != null;
this.trigonometricFunctions = trigonometricFunctions;
}
public void compute() {
…
double sinResult = trigonometricFunctions.sin(0.0d);
…
}
}
Tak o čem tu teda diskutujeme, pokud je správně aby byl sinus obyč funkce. Celé tohle vlákno se točí kolem toho že pro některé věci je obyč funkce to nejlepší a sinus tu padl jako příklad.Četl jste ten komentář, na který odpovídáte? Máte tři různé implementace jednoduché funkce, někde jsou dostupné všechny, někde třeba jenom jedna z nich. Uživatel té funkce nepotřebuje jednu konkrétní implementaci, on potřebuje nějakou implementaci, a pokud možno takovou, která je v dané chvíli nejlepší.
Já tam pořád nevidím ten důvod, proč by měl být sinus cokoliv jiného než jednoduchá funkce. O to tu snad celou dobu jde.Ne, nejde tu o to, že by sinus měl být cokoli jiného, než jednoduchá funkce. Jsou to různé jednoduché implementace – jednou je to jednoduchá funkce implementovaná instrukcemi pro celočíselnou aritmetiku, která bude fungovat všude. Podruhé je to jednoduchá funkce implementovaná instrukcemi pro aritmetiku v plovoucí řádové čárce. Potřetí je to jednoduchá funkce implementovaná pomocí instrukcí GPU. A já jako uživatel nechci vybírat, která implementace se použije – protože ani nemusí být vždy všechny dostupné.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.