Kniha Objektové programování od Čady

[Ivan Nový]

Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.

A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?

To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).

Dobrý program vypadá jako náčrtek :-)))

[Reklama]

[zboj]

Jinak i ve stavebnictví, v oboru s tisíciletou tradicí, se od nepaměti vede boj mezi stavebními konstruktéry, architekty na jedné straně a políry a zedníky na druhé straně. Jedni o druhých si myslí, že to jsou blbci a jejich výtvory stojí za zlámanou grešli :-)))

Tak to už bývá...

[Kit]

Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().

Není to stejné. Funkce fun(obj) se ve většině jazyků přetížit ani překrýt nedá.

To už se řeší v každém jazyku jinak a je hloupost o tom obecně teoretizovat.

Takže podle tebe je

Kód: [Vybrat]

adam.print()
kniha.print()totéž co

Kód: [Vybrat]

print(adam)
print(kniha)?

V prvním případě mi to s přehledem vypíše údaje o člověku (jméno, příjmení, věk) a také o knize (název, autor, vydavatel).

Pokud to budeš volat jako funkci, tak totéž jen tak neuděláš.

[gll]

„...i skladník ve šroubárně si může přečísti Vergilia v originále...“

Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost

Právě, že vyžaduje. Lidé co nečetli Vergilia, či něco podobného, většinou nechápou svět kolem sebe i když si myslí, že ho chápou. A pak ho taky stěží mohou modelovat. Naopak, čtenář Vergilia nemusí pracovat ve šroubárně, aby ji pochopil a mohl ji modelovat.

Jinak i ve stavebnictví, v oboru s tisíciletou tradicí, se od nepaměti vede boj mezi stavebními konstruktéry, architekty na jedné straně a políry a zedníky na druhé straně. Jedni o druhých si myslí, že to jsou blbci a jejich výtvory stojí za zlámanou grešli :-)))

Dnešním architektům by neuškodilo, kdyby současně rozuměli statice a řemeslu a nebrali architekturu jen jako kreslení obrázků. Michelangelo nebo Petr Parléř se řemeslu nevyhýbali a na jejich díle je to znát. Takovou hovadinu jako chobotnici na Letné by určitě nevymysleli.

[v]

V prvním případě mi to s přehledem vypíše údaje o člověku (jméno, příjmení, věk) a také o knize (název, autor, vydavatel).
Pokud to budeš volat jako funkci, tak totéž jen tak neuděláš.

o rozhraní (interface) už jste slyšel?

[Reklama]

[Kit]

V prvním případě mi to s přehledem vypíše údaje o člověku (jméno, příjmení, věk) a také o knize (název, autor, vydavatel).
Pokud to budeš volat jako funkci, tak totéž jen tak neuděláš.

o rozhraní (interface) už jste slyšel?

Ano, slyšel. Je nutné ho zde uvádět nebo musím poprosit puristy, aby mi bylo dovoleno to napsat ve stylu Pythonu?

Jak bys ty funkce (nikoli metody, ty jsou jasné) napsal s použitím rozhraní?

[gll]

Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.

A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?

To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).

Můžete to načrtnout i v reálném programovacím jazyku. Nemusíte uvádět implementace všech volaných funkcí.

[SB]

Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.

A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?

To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).

K té abstrakci x konkrétní jazyk: To mi připomíná způsob práce v nejmenované firmě, kde jsem dělal. Když bylo třeba vytvořit či rozšířit funkcionalitu aplikace, místo aby se nejprve obecně pojmenovaly entity a jejich činnosti, nakreslily na papír krabičky, domalovaly vztahy, z toho řešilo, jak to bude v doméně, následně v jazyku a v DB, tak se jako PRVNÍ začalo řešit, jak to bude uloženo v RELAČNÍ databázi. Výsledek: Vše odspodu nahoru podřízeno relační databázi včetně případných chyb, struktury, zpracování... Krása.

[Kit]

K té abstrakci x konkrétní jazyk: To mi připomíná způsob práce v nejmenované firmě, kde jsem dělal. Když bylo třeba vytvořit či rozšířit funkcionalitu aplikace, místo aby se nejprve obecně pojmenovaly entity a jejich činnosti, nakreslily na papír krabičky, domalovaly vztahy, z toho řešilo, jak to bude v doméně, následně v jazyku a v DB, tak se jako PRVNÍ začalo řešit, jak to bude uloženo v RELAČNÍ databázi. Výsledek: Vše odspodu nahoru podřízeno relační databázi včetně případných chyb, struktury, zpracování... Krása.

Tak jste mohli použít nerelační databázi, pokud jste chtěli efektivně ukládat nerelační data.

[Youda]

Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.

A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?

To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).

K té abstrakci x konkrétní jazyk: To mi připomíná způsob práce v nejmenované firmě, kde jsem dělal. Když bylo třeba vytvořit či rozšířit funkcionalitu aplikace, místo aby se nejprve obecně pojmenovaly entity a jejich činnosti, nakreslily na papír krabičky, domalovaly vztahy, z toho řešilo, jak to bude v doméně, následně v jazyku a v DB, tak se jako PRVNÍ začalo řešit, jak to bude uloženo v RELAČNÍ databázi. Výsledek: Vše odspodu nahoru podřízeno relační databázi včetně případných chyb, struktury, zpracování... Krása.

Coz je pro znacne procento aplikaci naprosto spravny postup.
Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join  genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.
Nebo ted nova moda, vsecko naser do elasticsearch a dej se vule bozi, obvykle navic opensource varianta elasticsearch s nulovou bezpecnosti.

V  realu, pokud bude aplikace pracovat s tabulkami se 100k zaznamy a vice, zakladem navrhu je ER model.
Osobne vubec v hibernatu nepouzivam transakce, mam je vyple. Vsechno potrebne balim do PLSQL procedur, ktere jsou z pohledu jawy atomicka operace. Nepouzivam ani JSQL, pozivam primo nativni SQL. Jdou v tom i takove "zazraky" jaomselect limit u MySQL, nebo IP aritmetika Postgresu.

[Mirek Prýmek]

Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join  genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.

...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka

[Ivan Nový]

Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join  genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.

...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka

Ono je to kvůli MS SQL, který nemá LIMIT, ale jen TOP, což se pro stránkování nedá použít.

[Kit]

Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join  genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.

...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka

Ono je to kvůli MS SQL, který nemá LIMIT, ale jen TOP, což se pro stránkování nedá použít.

To je právě ten problém. Pod záminkou přenositelnosti mezi databázemi jsou všechny degradovány na nějaký společný základ - ať to stojí, co to stojí.

[Ivan Nový]

Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join  genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.

...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka

Ono je to kvůli MS SQL, který nemá LIMIT, ale jen TOP, což se pro stránkování nedá použít.

To je právě ten problém. Pod záminkou přenositelnosti mezi databázemi jsou všechny degradovány na nějaký společný základ - ať to stojí, co to stojí.

Ale to je základní vlastnost toho prostředí, webu obecně, je polygenní. Na vině je HTML a CSS. Při vývoji webu se začalo od konce a to byla chyba. Kdyby klient byl jen automat ovládaný ze serveru a zprostředkovávající interakce s uživateli, celé prostředí by bylo efektivnější. Mělo se začít javascriptem, nebo ještě lépe lispem na straně klienta. Dnes bychom měli sémantický web, protože klient by sám generoval strojově interpretovatelné informace pro roboty vyhledávačů. Bohužel web vznikl v CERNU, tedy v prostředí orientovaném uživatelsky, ne programátorsky.

V prostředí IoT to bude jinak, tam prezentační vrstva bude chybět, což povede k větší efektivitě a novým paradigmatům kolektivního zpracování informace.

[SB]

Tak jste mohli použít nerelační databázi, pokud jste chtěli efektivně ukládat nerelační data.

To je přece buřt, do čeho to strkám. Důležité je, aby to bylo abstraktně odděleno jako vrstva, pak tam můžu použít pro ukládání třeba pozitronový mozek androida.