Co si myslíte o OOP?

[Kit]

Za sebe, pokud si mám vybrat mezi

Kód: [Vybrat]


int fn( int a, str b) {
  assert(a > 0);
}
nebo

Kód: [Vybrat]

fn(a, b) {
  assert(isInt(a));
  assert(isString(b));
  assert(a > 0);
}
,
volím první možnost - nejenom že je s tím míň práce, ale 2/3 testů tam zůstanou a po vypnutí asserce v release.

Ve skutečnosti však ta tvá první možnost vypadá takhle:

Kód: [Vybrat]

int fn( int a, str b) {
  assert(a > 0);
}

assert(isInt(a));
assert(isString(b));
fn(a, b);

takže jsi nic neušetřil, ale úlohu sis zesložitil. Odebral jsi funkci odpovědnost za validaci vstupu, ale zaměstnal jsi vstupní parser. Pokud budeš chtít změnit int na float, budeš muset měnit funkci i parser. Když změníš parser, budeš muset upravit i ostatní funkce, které jsou na datech z toho parseru závislé a v tuto chvíli akceptují stále jen ten int.

[Reklama]

[operator]

Urážkami na tom nic nezměníš.

Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky (a i to je dnes moc, aby sis u všech udržoval expertní znalosti, včetně souvisejícího ekosystému), než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. Rozdíl mezi mnou a tebou je jako rozdíl mezi praktickým hudebníkem a hudebním kritikem. Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit. A chceš-li to nazývat idiocií, prosím. Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo. Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.

Treba se naucite psat undo jako ja, operator. Sice to dela memory leaky a moc to nefunguje, ale zato mi to trvalo jenom pul dne.

Treba se naucite rozumet internim procesum jazyka, vyuzivat je a nebudete z toho vydeseny jako inkvizitor :-).

[Peva]

Za sebe, pokud si mám vybrat mezi

Kód: [Vybrat]


int fn( int a, str b) {
  assert(a > 0);
}
nebo

Kód: [Vybrat]

fn(a, b) {
  assert(isInt(a));
  assert(isString(b));
  assert(a > 0);
}
,
volím první možnost - nejenom že je s tím míň práce, ale 2/3 testů tam zůstanou a po vypnutí asserce v release.

Ve skutečnosti však ta tvá první možnost vypadá takhle:

Kód: [Vybrat]

int fn( int a, str b) {
  assert(a > 0);
}

assert(isInt(a));
assert(isString(b));
fn(a, b);

takže jsi nic neušetřil, ale úlohu sis zesložitil. Odebral jsi funkci odpovědnost za validaci vstupu, ale zaměstnal jsi vstupní parser. Pokud budeš chtít změnit int na float, budeš muset měnit funkci i parser. Když změníš parser, budeš muset upravit i ostatní funkce, které jsou na datech z toho parseru závislé a v tuto chvíli akceptují stále jen ten int.

Celkem pěkný příklad, který by navozoval dojem, že je vhodnější používat variantu 2. No, je to ale dáno tím, že se předpokládá, že s údaji bude po business stránce pracovat pouze ta JEDNA funkce. Jenže tak to ve skutečnosti nebude. Business logika je často komplexní a je rozprostřena do více method/objektů/funkcí....potom při variantě 2 je nutné  nějakým způsobem harmonizovat tu validaci...V tomto případě už přináší řešení 1 nesporné výhody.

[PetrM]

Ty první dva body jsou poněkud v rozporu s bodem třetím...

a) Záleží na situaci. Můžu mít M zdrojů a N zpracovatelů. Model 1:N je výhodnější se zpracováním na vstupu, N:1 u zpracovatele, zbytek někde mezi.
b) Pokud data předávám jako strukturu dat daných typů, provedu její naplnění při validaci (kdy stejně do dat sahám). Za předpokladu, že interně mám jako "flags" pole 32 bitů, nedává přece smysl interně jednou posílat string "acd" pro bity {0, 2, 3} a podruhý pro stejnou situaci číslo 13. Takže definováno je to na jednom místě - definice struktury. Pak je to definováno pro parsování vstupu ( to je pro OOP ideální - podle typu vstupu a typu dat si vyberu parser). Rozdíl je v tom, že v kontroléru pak taky neřeším typ dat - je prostě vždycky pro stejnou položku stejný, tak s s tím nezalamuju.

Prostě furt nevidím výhodu toho, že mám data a nevím, jak jsou zabalený.

Ve skutečnosti však ta tvá první možnost vypadá takhle..

Houbeles, nechápeš princip. U dynamickýho typování víš maximálně ty, co ti přijde za data. Většinou ani ty ne. A kompilátor/interpret se musí rozhodovat za běhu - mít připravený všechny varianty a kontrolní mechanismus na všechno. Takže mám menší a rychlejší kód.
Po zkompilování už se typ neřeší, je natvrdo zadrátovaný. A není ani důvod. Takže assert před vůbec není. Je řev kompilátoru, pokud se pokusím při parsování nacpat string do intu. Pak už to hlídat nemusím a za běhu nepadá "nevím co se stringem v proměnné", maximálně se ozve parser na vstupu, že se mu něco nelíbí.
A díky přetěžování funkcí vlastně ani nemusím řešit, čím to parsuju - podle toho, jaký typ chci, vybere kompilátor sám příslušnou parsovací funkci na vstupu.

Jenom si prostě při deklaraci interních řad řeknu, do čeho mají být zabalený a jak zabalený mají být vstupy/výstupy funkcí. Pokud to změním, dostanu při buildu echo, co jsem zapomněl nebo mám zkontrolovat. Ten boj proti nechápu - pokud teda dotyčný zná základy (jak se ukládá int, jak strimg, jak float, co  je to pointer,...) a tuší, jaký typy jsou k dispozici a co se pro jeho data hodí.

[UF]

neuveritelny - vy se musite skarade nudit

[Reklama]

[operator]

Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky [...] než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. [...] Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit.

Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").

Např. alespoň letmá znalost funkcionálního programování je afaik výborná proto, že se naučíš explicitně přemýšlet nad stavem - co s ním děláš, kam ho posíláš, kde se mění, kde se nemění atd. I v nefunkcionálním jazyce to může výrazně pomoct vyhnout se race conditions, zbytečným zámkům apod.

A právě proto je dobré třeba ten Haskell (nebo Elixir, Prolog, ...) alespoň párkrát zkusit, něco málo si v tom napsat. Pohrdat jím stylem "já jsem ten fachman, vy blbečcí akademičtí, mě vaše hračky nezajímají, protože vás musím živit" je hodně stupidní a omezený. Podobně stupidní jako "vy lopaty PHPkový si vykládejte co chcete, my jsme zasvěcenci páté úrovně haskellové gnóze!" Ne nadarmo byla po tisíciletí pýcha chápaná jako největší hřích...

To je pravda, ale jen castecne. Za prve v praxi potrebujes znat vice jazyku, protoze zadny univerzalni neexistuje. Ale cim mene jich je, tim lepe jim muzes rozumet. Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku. V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat. Viz pocatek diskuse a narky nad tim, ze je to spatne a jazyk to komplikuje. Za treti netyka se to jen paradigmat, ale i metodik vyvoje, a plati to i na tady odsuzovane dynamicke rysy jazyku, kterych se tu nekteri desi. I programovani v dynamickem jazyce potrebuje jiny pohled na vec. Mozna vic jiny, nez funkcionalni programovani. Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.

[PetrM]

To je pravda, ale jen castecne. Za prve v praxi potrebujes znat vice jazyku, protoze zadny univerzalni neexistuje. Ale cim mene jich je, tim lepe jim muzes rozumet. Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku. V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat. Viz pocatek diskuse a narky nad tim, ze je to spatne a jazyk to komplikuje. Za treti netyka se to jen paradigmat, ale i metodik vyvoje, a plati to i na tady odsuzovane dynamicke rysy jazyku, kterych se tu nekteri desi. I programovani v dynamickem jazyce potrebuje jiny pohled na vec. Mozna vic jiny, nez funkcionalni programovani. Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.

Jenomže jsou jazyky, kde je něco neuvěřitelně složitý nebo komplikovaný a pokud nemáš jistotu, že i přes ty komplikace je to to nejlepší, tak to paradigma prostě nepoužiješ. Ono objektově se dá jet i v ASM, když na věc přijde, ale ASM je neskutečný opruz sám o sobě a když tam dáš něco navíc, tak je to ještě větší peklo.

A někdy i jiný jazyk má interní funkcionalitu, která se ti vybaví při práci v jiným jazyku - místo hledání jednorázovýho řešení si uděláš reusable modul, který simuluje chování jinýho jazyka (mám třeba v Cčku obdobu množin z Pascalu, ale přeloženou s BitBandem pro Cortexy, systém výjimek z C++, cykly jako foreach pro seznam,...). Takže víc jazyků i víc paradigmat se ti vrátí.

[Peva]

Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.

Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.

[Kadet]

P.S. Kadete, k těm typům. Je lepší hodinu bojovat se statickými typy, než týden hledat, proč se to číslo chová divně. Schválně, mám SessionID 231479973001 a používám to jako číslo ve formátu UINT64. Co dostanu, pokud ho první knihovna interně konvertuje do UINT32 (protože na ni od dob 32b nikdo nesáhl), druhá do INT64 (protože signed považuje za nativní formát) a pak zpátky do UINT64? Jaký budeš mít SessionID na konci toho procesu? A uspokojí tě to? Ale co, hlavní je, že ani ty tři warningy při buildu nedostaneš... A to se počítá.
Takže na začátku parsování/verifikace dat na jednom místě, následná logika pak ví, že data jsou validní a jak jsou zabalený. A pokud jsou zabalený jinak, kompilátor to zatepla nabonzuje...

Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu. Ja bych taky odmitnul pracovat na prasecim Python projektu, kdybych tam videl praseciny podobnyho typu. Taky bych byl radsi kdyby to bylo staticky otypovany.

Jenze ja bych vzal ten prasecak, pokusil se najit co se to snazi delat, tj. najit vstupy a vystupy a jak to komunikuje s okolnim svetem, a vyhazet 90% toho chliva ven.

Presne to taky delam ve svy praxi. V tvym pripade bych vyhazel vsechny th black box knihovnh co mi znasilnujou session id, session id bych nahradil pouhym stringem, protoze nepotrebuju delat aritmetiku ani pocitatncialni rovnice se session id.

Kod bych zredukoval na desetinu mozna min ve zlomku casu. To co ostatnim trva mesice, ja dodavam do tydne. Protoze dokazu rychle najit co je v programu potreba a co je balast.

Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat. Takze vezmu kritickou sekci a prepisu ji v Cythonu, v C nebo necim podobnym. Nebo napisu kritickou sekci jako cistej C, java program a pospojuju to unix pipelinou. Je mi to prakticky jedno. A vis co. Dneska jsou komoy tak rychly, ze klient radsi zaplati za dve dalsi masiny misto prepisu do rychlejsiho jazyka.

[PetrM]

Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu...

Já preferuju vlastní kód, ale nikdo ti nezaplatí vývoj vlastních knihoven. Vždycky používáš kód třetí strany a inspekce od kompilátoru se vždycky hodí (resp. je zadarmo).  "Model světa" totiž musíš přechrchlat na byty, aby jim stroj rozuměl a to jsou najednou chyby jak víno. Zaokrouhlování u floatů, přetečení nebo podtečení hodnot,... Prostě je fajn si říct, že to bude tak a ještě lepší si to restriktivně vynutit.

Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.

Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:

Krok |	Typ	| Dekadicky	| Hexadecimálně	| Podrobnosti
0	| uint64	| 231479973001	| 0x0000000035E5481489	| hodnota má 40b
1	| uint32	| 3846706313	| 0xE5481489	| přišli jsme o horních 8b hodnoty
2	| int64	| -448260983	| 0xFFFFFFFFE5481489	| bit 31 = 1 -> záporné číslo
3	| uint64	| 18446744072813029651	| 0xFFFFFFFFE5481489	| Interpretováno jako UINT64

Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...

Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.

[Ondrej Nemecek]

Nejlepší jsou silně typované jazyky s pozdní vazbou 

Akademici mají na slunci taky své místo, není vše jen o praxi.

A už se nehádejte, stejně to jde odnikud nikam

[Kadet]

Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu...

Já preferuju vlastní kód, ale nikdo ti nezaplatí vývoj vlastních knihoven. Vždycky používáš kód třetí strany a inspekce od kompilátoru se vždycky hodí (resp. je zadarmo).  "Model světa" totiž musíš přechrchlat na byty, aby jim stroj rozuměl a to jsou najednou chyby jak víno. Zaokrouhlování u floatů, přetečení nebo podtečení hodnot,... Prostě je fajn si říct, že to bude tak a ještě lepší si to restriktivně vynutit.

Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.

Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:

Krok |	Typ	| Dekadicky	| Hexadecimálně	| Podrobnosti
0	| uint64	| 231479973001	| 0x0000000035E5481489	| hodnota má 40b
1	| uint32	| 3846706313	| 0xE5481489	| přišli jsme o horních 8b hodnoty
2	| int64	| -448260983	| 0xFFFFFFFFE5481489	| bit 31 = 1 -> záporné číslo
3	| uint64	| 18446744072813029651	| 0xFFFFFFFFE5481489	| Interpretováno jako UINT64

Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...

Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.

Opet, pocitas snad integraly a derivace se session id? Ja ne, proto to necham jako string a nic vic neresim.

Floaty maji velmi omezeny pouziti v byznys aplikacich. Penize nikdy nereprezentujes jako float pokud nejsi prase.

Kdyz teda operujes na urovni systemu a ne jen pouhyho izolovanyho programu, jako v tvym priklade klientu a serveru, tak ti kompilator v nicem nepomuze. Ten zkontroluje jen ty casti, ale ne celek. Opet, pokud si prase a nedokazes zajistit ze komunikacni protokol mezi podsystemy je spravne, nepomuze ti kompilator ani panenka maria.

Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.

[agent]

...Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat....

Tohle mě zaujalo.
Kdo ti tu optimalizaci zaplatí, pokud je klient už spokojený s právě hotovou verzí aplikace?
Realita te taková, že jakmile má projekťák od zákazníka akceptaci (za co nejméň nákladů = první verze se kterou je zákazník spokojený), předá to k fakturaci a ty dostaneš jinou práci.

[BoneFlute]

Tak ono furt platí, že
1) Jak dostanu z vnějšku nějakou hodnot, musím ji validovat -> validátor / parser tam stejně bude
2) Chybu mám zachytit a ošetřit co nejdřív.
3) Věci by měly být řešeny na jednom místě (SRP)

Ty první dva body jsou poněkud v rozporu s bodem třetím. Data z vnějšku klidně nechám probublat až do objektu, který je v zvaliduje až ve chvíli, kdy s těmi daty potřebuje pracovat. Tedy naopak je validuji co nejpozději. Pokud ta data proudí z více zdrojů, tak jsou validována právě v tom jednom objektu, který se stará právě jen o tento typ dat. O data jiného typu se stará jiný objekt, i když jsou součástí toho jednoho požadavku.

Tento přístup mi umožňují dělat poměrně jednoduché kontrolery, které se o validaci nestarají, ale pouze se rozhodují, které komponenty modelu použijí a jak je zkombinují.

Ano. A je to velmi špatně.

[BoneFlute]

Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.

Kód: [Vybrat]

~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"

Tohle mi přijde jako fajn řešení, kdy mohu "odložit" statickou kontrolu. Užitečná informace. Jsem o pythonu nevěděl. Dík.