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.


Příspěvky - Filip Jirsák

Stran: 1 ... 317 318 [319] 320 321 ... 375
4771
Vývoj / Re:Java a statické metody
« kdy: 22. 10. 2015, 11:45:24 »
Implementace sinu se volí v době překladu protože na nějaké rozskakování za běhu nemá moc cenu. Spláchnutí pipeline které je s tím spojené se prostě nevyplatí. Sinus je tak low level, že jediná smysluplná volba podle platformy probíhá při překladu.
Při překladu Java programu bude cílovou platformou JVM, na tom není moc co řešit. Což ale vůbec neznamená, že nemůžete mít různé implementace – pár příkladů už jsem vyjmenoval. Vůbec není potřeba dělat nějaký rozskok za běhu programu – prostě budete mít mezi knihovnami při startu aplikace jednou knihovnu s jednou implementací, a příště tam dáte jinou implementaci.

4772
Vývoj / Re:Java a statické metody
« kdy: 22. 10. 2015, 11:19:19 »
A tohle je argument pro to že pro sinus nestačí úplně jednoduchá funkce? Přece implementace té funkce závisí na platformě.
Implementace té funkce závisí na něčem. Takže nemůžu mít ve svém programu závislost na jedné konkrétní implementaci. Kdybych si dal do své aplikace závislost třeba na implementaci, která používá GPU, nebude to fungovat na zařízení, které žádné GPU nemá.

4773
Vývoj / Re:Java a statické metody
« kdy: 22. 10. 2015, 10:42:02 »
Já zírám. Opravdu někoho napadne, že by implementace sinu měla jít přehazovat za běhu? Tohle už snad není ani overengineering.
Nemusí jít přehazovat za běhu, ale výběr nejlepší možné implementace je logický. Proč bych to mám všude počítat pomalým způsobem jenom proto, že na některých platformách není rychlejší způsob dostupný?

To, že jsou různé algoritmy schované za tou funkcí je přece výhoda. Mně nezajímá postup ale počet platných číslic co dostanu.
Takže jste si to nakonec vysvětlil sám, že by kód neměl záviset na konkrétní implementaci.

4774
Vývoj / Re:Java a statické metody
« kdy: 22. 10. 2015, 10:05:46 »
TransformJsonToXML nepatří ani do třídy Json ani do třídy XML a nepotřebuje ani svou vlastní třídu když je to pouze jedna procedura.
Ta jedna procedura má na vstupu String, InputStream, Reader, URL, File, na výstupu String, OuptutStream, Writer, URL, File, SAX ContentHandler, StAX, W3C DOM Document, dom4j Document, JDOM Document. A dále potřebuje JSON parser a XML serializer. Bude ta jedna procedura mít desítky přetížených variant, nebo to bude spíš rozhraní a třeba JSON parser a XML serializer budou schovány v jedné konkrétní instanci implementující to rozhraní?


Tak ukaž objektový adaptér na sin, cos, tan spolu se zdůvodněním proč to tak má být :)
Opět to samé jako v předchozím případě – můžu mít různé implementace (různé algoritmy, implementace využívající celočíselnou aritmetiku, aritmetiku v plovoucí řádové čárce, využívající GPU). Uživatel asi nechce být závislý na nějaké konkrétní implementaci. Spíš bude záviset na rozhraní, a za běhu dostane v danou chvíli nejlepší dostupnou implementaci.

4775
Vývoj / Re:Java a statické metody
« kdy: 22. 10. 2015, 06:53:11 »
Tazatel je začátečníkem. Proč se ho všichni snaží naučit těm nejšpinavějším praktikám, které se dnes používají? Je nutné začít co nejčistějšími objekty.
To, že OOP je jediný správný přístup a všechno ostatní je špinavé, je čistě váš názor.


Nikdo z nás asi nemůže za to, že mnoho základních knihoven Javy je napsáno prasácky a s neobjektovým rozhraním. To však nesmí být důvodem, proč bychom je měli napodobovat. Je potřeba si na ně napsat vlastní objektové adaptéry a ty používat.

Častým argumentem je, že přísně objektové aplikace jsou pomalé. Není to pravda. Mám opačnou zkušenost: Refaktorováním cizích aplikací do objektů se mi tyto aplikace zkrátily, zpřehlednily a zrychlily. Během přepisu z nich zmizely i chyby, které v původním programu nebyly nijak zřetelné, ale do toho objektového modelu mi "prostě nepasovaly". Přitom běžně stačilo tu postiženou část kódu zcela vypustit, protože byla duplicitní.

Objekty mají data a chování. Přitom si obecně data chrání a vystavují pouze chování.
Tohle asi začátečníkovi moc nepomůže. Popište to na nějakém konkrétním případu, jaké tam budou objekty a co budou dělat. Třeba košík e-shopu s vloženým zbožím, údaje se načítají z relační databáze a vypisují na webovou stránku.

Pokud se někdo pokouší objekty rozdělit na datové a servisní služby, měl by se raději poohlédnout po jiných programovacích jazycích, než je právě Java.
Proč? V Javě se takhle programuje dobře, má pro to spoustu frameworků a je tak napsaných spousta programů.

4776
Vývoj / Re:Java a statické metody
« kdy: 21. 10. 2015, 19:28:54 »
Obávám se, že „best practices“ nemůže označovat něco, co skoro nikdo nepoužívá. Ano, váš návrh je čisté OOP, ale to se dnes příliš nepoužívá – dnes se většinou programuje v objektových jazycích a s objekty, ale aplikace fungují procedurálně. Je to mimo jiné proto, že „starat se o data“ lze mnoha různými způsoby, které nepatří na jednu hromadu, a dokonce často ani nemusí být všechny předem známy.

4777
Vývoj / Re:Java a statické metody
« kdy: 21. 10. 2015, 11:33:28 »
Pokud ten "pravy" singleton nema zadne dalsi zavislosti, nebo aspon implementuje nejake rozhrani tak to testovatelne je celkem bez problemu (uzivatele toho singletonu samozrejme nesmi pouzivat MySingleton.getInstance(), ale klasicky dependenci injection).
Což je přesně to, co Natix nazývá „efektivní singleton“ a o čem jsem já psal jenom jako o „singletonu“ – prostě uživatel používá nějakou třídu nebo rozhraní, a nestará se o to, odkud vezme implementaci. Za normálního běhu aplikace typicky bude existovat jenom jedna jediná instance, proto se to nazývá singleton – ale nic nebrání mít třeba pro testy jinou implementaci, případně mít za běhu aplikace těch instancí víc a pro dané použití nějakým způsobem vybrat jednu z nich.

Singleton, na který je jeho uživatel pevně navázán (tj. sám získává jeho instanci voláním třeba getInstance()) má z hlediska použití skoro ty samé nevýhody, jako statické metody.

4778
Studium a uplatnění / Re:Studium kernelu
« kdy: 20. 10. 2015, 20:13:08 »

4779
Vývoj / Re:Java a statické metody
« kdy: 20. 10. 2015, 16:29:31 »
Ten příklad je k ničemu, protože o tom, zda je lepší singleton nebo statické metody, se budete rozhodovat podle kódu těch metod, ne podle jejich hlavičky.

Důvod pro tu jednu instanci je tehdy, pokud ten kód těch metod bude trochu složitější, a budete z nich volat jiné metody a jiné služby.  V případě statických metod pak musíte mít závislost na těch jiných službách natvrdo v kódu, a nezměníte ji ani třeba pro účely testů. V případě singletonu předáte ty závislosti jako parametr při vytváření té instance, takže pokud ji potřebujete vyměnit, jenom zavoláte konstruktor s jiným parametrem, ale na té implementaci singletonu nic neměníte.

Collections.sort() je zrovna případ, který by bylo lepší řešit pomocí singletonu – a jako statické metody je to řešeno jednak kvůli stáří té třídy (přeci jen v té době poněkud chyběly Java best practices), jednak aby se to snadno použilo i ve velmi primitivních aplikacích. Jinak by bylo rozumné té třídě umožnit předat třeba implementaci řadicího algoritmu, výchozí comparátor, výchozí locale pro řazení apod.

4780
Vývoj / Re:Java a statické metody
« kdy: 20. 10. 2015, 13:52:20 »

Normálně to právě vím. A připadá mi mnohem lepší zápis Math.max(a, b), než když vidím napsáno jenom max(a, b) a musím pátrat po tom, zda je to Math.max(a, b) nebo VectorUtils.max(a, b) nebo ještě něco jiného.

4781
Vývoj / Re:Java a statické metody
« kdy: 20. 10. 2015, 13:09:25 »
Spolu se statickymi importy dostanes o neco citelnejsi kod. Ja bych v tomhle byl pragmatik - pokud je to pure (nebo skoro pure, trebas logovani se da osolichat i jinak) a neni to navazane na konkretni data (kde jasne dava smysl instancni metoda), tak bych se statickych metod nezrikal. Ostatne kdyz se pouzivaji takhle zaroven to signalizuje i ucel.

Takze jako obvykle - resil bych to pripad od pripadu.
Podle mne statické importy obvykle kód znepřehledňují, protože nevím, odkud se ta metoda bere…

To rozlišení jsem psal o něco dříve – pokud ten kód nezávisí na ničem dalším a určitě nikdy v budoucnosti záviset nebude, tedy pokud jsou to typicky jednořádkové nebo třířádkové metody, použil bych util třídu se statickými metodami. Jakmile tam je nějaká logika, dá se očekávat, že tam budou vznikat nějaké závislosti nebo vytýkání kódu, použil bych singleton – ušetřím si tím problémy v budoucnosti.

4782
Vývoj / Re:Java a statické metody
« kdy: 20. 10. 2015, 12:47:03 »
s osmickou jsou staticke metody celkem obstojne nahrazky funkci
Předpokládám, že vám jde o lambda výrazy – a tam je použití instanční metody úplně stejné, jako použití statické metody. Takže tohle není argument na podporu statických metod.

4783
Vývoj / Re:Java a statické metody
« kdy: 20. 10. 2015, 10:33:54 »
Pokud je to opravdu triviální utilita, která určitě nebude záviset na ničem dalším (např. často testujete, zda řetězec není prázdný, tj. zda není null nebo nemá délku 0 – tak si ty dvě podmínky složíte do jedné metody), dělá se to opravdu tak, že vytvoříte finální třídu se statickými metodami, vytvoříte v ní privátní bezparametrický konstruktor, který vyhazuje výjimku (takže instance nepůjde vytvořit ani děděním nebo reflexí).

Často ale ten kód bude složitější, bude záviset na dalším kódu (nebo to tak může být v budoucnosti). Pak se ta implementace píše jako klasická třída, od které se pak v aplikaci vytvoří jediná instance – singleton. Tahle třída pak může záviset na jiných třídách – a díky tomu, že to jsou instance (které předáváte typicky v konstruktoru, nebo alespoň pomocí setterů), můžete pak implementaci snadno vyměnit, aniž byste musel zasahovat do kódu. Což se hodí třeba v případě testů. Nejspíš brzy dojdete k tomu, že takovýchhle tříd budete mít víc a budou mít různě propletené závislosti – pak se vám hodí nějaký IoC framework, který ty instance bude vytvářet za vás a bude řešit ty závislosti. A obvykle vám pak umožní jenom změnou konfigurace určit, která implementace se má použít.

Jinak to, že máte služby, které dělají jenom nějaké transformace s datama, je naprosto běžná věc. Funguje takhle nejspíš drtivá většina evidenčních aplikací (e-shopy, účetnictví, sklady atd.). Proto také vzniká tolik frameworků, které takovou architekturu programů podporují – ORM, IoC apod. Je to návrat k procedurálnímu programování. V C máte datové struktury a procedury/funkce, které s daty manipulují. Dnes se sice programuje s objekty, ale ve skutečnosti tam často máte zase jen datové entity nebo přepravky, tedy datové struktury, které nemají žádný výkonný kód, a vedle nich služby, které s těmi daty manipulují (ale nemají žádný stav) a které se typicky dělají jako bezstavový singleton.

4784
Windows a jiné systémy / Re:Informace o aplikaci pro Android
« kdy: 19. 10. 2015, 19:10:44 »
Pokud umíte aspoň trochu v PHP, napište si na to aplikaci v PHP a v mobilu jenom zobrazíte stránku ve webovém prohlížeči. Bude to nesrovnatelně jednodušší.

4785
Sítě / Re:Mikrotik - jedinecne ID hosta
« kdy: 19. 10. 2015, 14:35:36 »
Ne.

Stran: 1 ... 317 318 [319] 320 321 ... 375