Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 11:33:01 »
To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý).
No a v objektovém návrhu, jak ho chápu já, by naopak spíše objekt toužící po serializaci jiného objektu (exportu do jiného formátu...) poskytl takovému objektu objekt, pomocí kterého si to ten inkriminovaný objekt zařídí sám. Tím netvrdím, že opačný přístup je chybný, spíše bych řekl, že ve skutečnosti jen není objektový, protože narušuje zapouzdření. Ve skutečnosti může být (a také asi bude) jednodušší a efektivnější - znalost nějakých vnitřních detailů objektu může spoustu věcí usnadnit, naopak - blackboxing "za každou cenu" může vést k neřešitelným (nepředvídatelným) situacím při návrhu rozhraní. Ale to se dostáváme k samotné filosofické otázce, zda tedy vůbec OOP.

Může být. Podle mého jsou legitimní oba přístupy. Ten objekt může poskytnout svoji kanonickou reprezentaci, metody pro její iterování nebo mít metody pro serializaci a deserializaci skrze nějaké abstraktní rozhraní. V obou případech ale považuji za klíčové, aby to bylo abstraktní, ne vázané na konkrétní formát.

Ty přístupy mají svoje pro a proti. Např. když ta metoda pro načtení/uložení bude v té třídě, tak ji musí někdo napsat. Zatímco když to bude řešené přes reflexi, tak to mám zadarmo, maximálně tam přidám nějakou tu anotaci, když chci něco jinak (třeba že tenhle atribut nechci v XML nebo v DB nebo že se má přejmenovat), nebo to můžu definovat na jednom místě (že chci třeba názvy v Javě jako CamelCase, zatímco v XML jako lisp-case, nebo definuji globálně formát data atd.). Může to být v externím konfiguráku nebo kódu a ty de/serializované třídy o tom vůbec nemusí vědět.

Pak můžeme narazit na problém prosakující abstrakce. I když si uděláme krásně abstraktní rozhraní, tak někdy můžeme chtít ovlivnit, jak se nějaký atribut bude v konkrétním formátu de/serializovat. To je řešitelné přes anotace (JPA, JAXB…) nebo přes externí konfiguraci (viz taky JPA nebo JAXB…) nebo tam můžu mít nějakou volnou strukturu, mapu klíč-hodnota, do které připojím nápovědu, jak to de/serializovat v konkrétním formátu (ta struktura je pořád obecná, abstraktní a klíče by měly být globálně unikátní, typicky URI).
2
Hardware / Re:Vyplatí se spotový elektroměr a server
« Poslední příspěvek od uwe.filter kdy Dnes v 11:31:38 »
Mám docela komplexní zapojení a opravdu to předělat můžou být desítky hodin práce + tu hodinu práce jsem schopen prodat třeba za 1.000 Kč / hodina, takže ekonomika to předělat nemusí zrovna sedět.

Myslím, že sis odpověděl sám :-). Jestli tu práci prodáš za 1000 Kč/hodinu, asi tě nemusí moc trápit těch 1000 Kč měsíčně za elektřinu. A kdyby tě to přecejen časem moc trápilo, tak to holt předěláš a služby rozložíš na "musí běžet pořád" vs. "nemusí běžet pořád" a ty nabyté znalosti pak taky zužitkuješ.
3
Odkladiště / Re:Jak odpovědět na výhružný dopis od BSA?
« Poslední příspěvek od zra kdy Dnes v 11:31:30 »
bral bych xxx@bsa.org . To co přišlo zahodit a více neřešit.
4
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Zdenek Tomes kdy Dnes v 11:25:41 »
To je nepatřičná zkratka. Fyzické objekty většinou mají identitu, ta se nemění. A jejich stav se v čase může měnit (jinak by to byla konstanta), ale ten stav samotný ("otisk objektu") bude hodnotou, která je immutable, že? Nebo naopak: modifikace nějakého atributu objektu vede ke změně jeho stavu (to asi souhlasí), ale identita je zachována.

Ale asi souhlas s tím, že čím víc se vzdalujeme od matematiky (kde se pracuje s immutable hodnotami) k fuzzy reálnému světu, tím míň je funkcionální přístup přirozený.
Ta identita je jen naše abstrakce. Při bližším pohledu to drhne (např. Theseova loď nebo dědečkova sekera).

A i ten "fyzický objekt" je naše škatulka, navíc kapku neostrá.

Směřuju k tomu, že když o něčem mluvíme, tak obvykle žonglujeme s abstraktními immutable objekty, které existují leda tak v nějakém paralelním myšlenkovém nebo platonickém světě. Mapování na nějaké immutable reprezentace není nějaká matematická specialitka, děláme to úplně běžně že to ani nevnímáme.

Ano, identita je abstrakce, přesně tak. Umožňuje nám pracovat s "objekty", které se z fyzikálního hlediska mohou měnit. Jak píšeš a budu parafrázovat: identita "Jiří Havel" bezpochyby jako reprezentace objektu existuje, má mnoho referencí uložených jinde (pošta Ti doručí dopis, úřad Tě dokáže zpárovat - tedy většinou), ale třeba na úrovni molekul/atomů je to naprosto jinej objekt, než v době narození. Nicméně identita stále existuje.
5
Odkladiště / Re:Co to byl web Geocities?
« Poslední příspěvek od Honza1Ubuntu kdy Dnes v 11:19:03 »
Archiv Geocities jsem našel tady:

https://thepiratebay.org/description.php?id=6353395

Velikost 641.4 GiB jako 7z archív. Po rozbalení okolo 900 GiB. Tenkrát byly weby a soubory malé, internet pomalý a i kapacita malá. Šetřil se tedy každý kiB. Musí tam tedy být eextrémní množštví webů. Stáhnutí každého 1 MiB v 90-letech trvalo nějakých 6 minut a stálo 1.5 Kč jesli správně počítám.

Dneska nikdo nešetří s místem na disku, s traffic nebo s CPU a Ram, což je docela vidět.

Mohl bych i zkusit ten archív rozbalit a zkomprimovat s lepší kompresí.

Ještě jsem našel malý archiv 51 000 midi souborů z Geocities:
https://thepiratebay.org/description.php?id=5161696

Ten jsem si stáhnul, vše funguje. Ale třeba najít konkrétní známou nebo Českou skladbu je složité.

Ještě jeden původní torrent Geocities od uživatele Jason Scott. Tam je nehspíš horší kompese nebo segmentování oprotí novému Torrentu (Nový torrent je po 16 MB částech). NIcméně odkazy dávám oba pro možnost přečtení popisu:

https://thepiratebay.org/description.php?id=5923737
6
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Jiří Havel kdy Dnes v 11:13:57 »
To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý).
No a v objektovém návrhu, jak ho chápu já, by naopak spíše objekt toužící po serializaci jiného objektu (exportu do jiného formátu...) poskytl takovému objektu objekt, pomocí kterého si to ten inkriminovaný objekt zařídí sám. Tím netvrdím, že opačný přístup je chybný, spíše bych řekl, že ve skutečnosti jen není objektový, protože narušuje zapouzdření. Ve skutečnosti může být (a také asi bude) jednodušší a efektivnější - znalost nějakých vnitřních detailů objektu může spoustu věcí usnadnit, naopak - blackboxing "za každou cenu" může vést k neřešitelným (nepředvídatelným) situacím při návrhu rozhraní.
Ona jakákoliv serializace bude v principu narušovat zapouzdření, jinak nemůže fungovat. Je jen otázka, jestli to není zapouzdřené až na úrovni toho xml, nebo už někdy dřív.
Citace
Ale to se dostáváme k samotné filosofické otázce, zda tedy vůbec OOP.
Dobrá otázka je i "Co je to vůbec OOP?". Odpověď není až tak jednoduchá :)
7
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 11:13:28 »
Ale co třeba takové:
Kód: [Vybrat]
vaha.zvazit(osoba)
osoba.zvazitSe(vaha)
Je něco z toho zjevně dobře nebo zjevně špatně?

Někdy se hovoří o IoC (inversion of control) a jeden směr se považuje za klasický/běžný a druhý za obrácený. Jindy je to jsou oba rovnocenné a nedá se ani říct, co je obrácené a co není. Viz např. push a pull parsery, nebo si můžu zaregistrovat posluchač a čekat až mi přijde událost nebo se naopak dotazovat na další událost. Používají se oba přístupy a ani jeden bych asi nepovažoval za zvěrstvo. Nevím, jaký konkrétní případ měl Standa na mysli, ale ve mne to vyvolalo vzpomínku na to, co píšu v odstavci „Píšu o problému, na který občas narážím v praxi…“.

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).
Pak ovšem musíš vnitřní stav toho objektu zpřístupnit vnějšímu světu (pro serializaci a deserializaci), což porušuje princip zapouzdření.

Proto by tam měl být ten mezikrok s tím kanonickým tvarem – objekt poskytne nějaká abstraktní data (nebo metody pro jejich iterování), třeba nějaký abstraktní strom nebo graf uzlů a jejich atributů… a pak bude jiná třída, která tuhle abstraktní-kanonickou reprezentaci projde a vyrobí z ní konkrétní formát. Zrovna v Javě je tohle už vestavěné ve formě reflexe, takže můžeme mít třeba JAXB, který umí ukládat a načítat objekty do/z XML, aniž by tyto objekty musely cokoli vědět o XML a obsahovaly nějaký specifický kód pro XML. Stejně tak může existovat podobný mechanismus pro mapování na JSON nebo třeba relační databázi nebo cokoli jiného. Ten objekt resp. třída může dát nějakou nápovědu, jak co mapovat (anotace JAXB, JPA atd.), ale taky to může jít úplně mimo ní a může to být v nějakém externím XML souboru, který řekne JAXB nebo JPA, jak se co mapuje.

Nebo považuješ i ten kanonický tvar za porušení zapouzdření? Svým způsobem to porušení je. Otázka jak to řešit – např. C++ má koncept přátelských tříd (friend), nebo to můžu zpřístupnit v rámci nějakého balíčku nebo modulu a pro ostatní uzavřít… Případně řídit přístup k reflexi na úrovni jazyka resp. běhového prostředí. Ale pokud má mít kdokoli možnost napsat si de/serializátor pro svůj formát, tak ta kanonická reprezentace přístupná být musí. Nevidím v tom moc problém. (ostatně kdyby ta třída v sobě měla zadrátovanou třeba metodu saveAsXml(OutputStream), tak se k datům dostanu tamtudy – ta kanonická reprezentace mi přijde určitě lepší).
8
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Kit kdy Dnes v 11:11:07 »
To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý).
No a v objektovém návrhu, jak ho chápu já, by naopak spíše objekt toužící po serializaci jiného objektu (exportu do jiného formátu...) poskytl takovému objektu objekt, pomocí kterého si to ten inkriminovaný objekt zařídí sám. Tím netvrdím, že opačný přístup je chybný, spíše bych řekl, že ve skutečnosti jen není objektový, protože narušuje zapouzdření. Ve skutečnosti může být (a také asi bude) jednodušší a efektivnější - znalost nějakých vnitřních detailů objektu může spoustu věcí usnadnit, naopak - blackboxing "za každou cenu" může vést k neřešitelným (nepředvídatelným) situacím při návrhu rozhraní. Ale to se dostáváme k samotné filosofické otázce, zda tedy vůbec OOP.

Tím jsme se dostali k DIP, v C# reprezentovány například delegáty.
9
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Jožka Niemand kdy Dnes v 10:58:49 »
To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý).
No a v objektovém návrhu, jak ho chápu já, by naopak spíše objekt toužící po serializaci jiného objektu (exportu do jiného formátu...) poskytl takovému objektu objekt, pomocí kterého si to ten inkriminovaný objekt zařídí sám. Tím netvrdím, že opačný přístup je chybný, spíše bych řekl, že ve skutečnosti jen není objektový, protože narušuje zapouzdření. Ve skutečnosti může být (a také asi bude) jednodušší a efektivnější - znalost nějakých vnitřních detailů objektu může spoustu věcí usnadnit, naopak - blackboxing "za každou cenu" může vést k neřešitelným (nepředvídatelným) situacím při návrhu rozhraní. Ale to se dostáváme k samotné filosofické otázce, zda tedy vůbec OOP.
10
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Kit kdy Dnes v 10:52:16 »
Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).
Pak ovšem musíš vnitřní stav toho objektu zpřístupnit vnějšímu světu (pro serializaci a deserializaci), což porušuje princip zapouzdření.

V tomto smyslu porušují zapouzdření všechny gettery a settery. Přesto je kdekdo používá.
Stran: [1] 2 3 ... 10