Příspěvky

1426

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 06. 06. 2018, 23:13:14 »

Ty objekty vždy něco reprezentují. Například Máslo reprezentuje entitu másla. Má nějaké vlastnosti jako velikost, váhu, výrobce...

Pak mám samozřejmě nějaké úložiště Lednice, Košík. To má také nějaké vlastnosti, třeba kapacitu.

Potud všechno jako podle knižního ideálu reprezentuje objekty reálného světa.

Jenže pak máte věci, které jsou taky objekty. A to jsou procesy. Například proces Nákup, DodáníZboží, Naskladnění, Inventura. To jsou také naprosto plnohodnoté objekty. V nich figurují víše uvedené objekty, ale také je zde hlavně uložena logika toho procesu (různé ACL, posílání výkazů, strhávání plateb, etc). A právě tady, protože to korensponduje s tím názvem.

Samozřejmě bychom tu logiku mohli hodit do vhodně pojmenovaných metod, a ty přilepit k více méně adekvátnímu objektu (Máslo se umí Nakoupit, nebo spíše Lednice umí Nakoupit?). Nemyslím si, že by to pak bylo objektovější - spíše naopak; třeba už jen z toho důvodu, že nemůžem nahrazovat procesy jak se nám líbí: Pepa umí Nakoupit, DodatZboží, Naskladňovat...

1427

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 06. 06. 2018, 20:00:09 »

Učebicové OOP říká, že máme dát metodu save() přímo do User.

Ještě jsem takovou učebnici neviděl. Ale někteří vývojáři začínající s OOP to takhle implementují, to jo.

... ale je to v principu kravina.

... to je kravina.

Výborná argumentace.

Daleko více připomíná procedurální programování než OOP: to POJO je datová struktura a to DBUtil je zpracovávající mechanismus.

Procedurální je o něčem jiném.

Jenže v modetě save() v Userovi se přece nemůže zpracovávat i Company a Address, to je kravina.

Také to tak v čistém OOP být nemá. Metoda User.save() má uložit stav uživatele – asi to bude znamenat i uložit nějaké vazby na Company a Address, např. jejich ID. A Company a Address zase budou mít své metody save(), které se postarají o uložení konkrétních objektů.

Ano, to by bylo krásné, jenže nemůžete uložit jen tak Usera s id Company, když Company ještě není uloženo a tudíž ten klíč zatím v DB neexistuje.

Proč by to nešlo? To víš, že to jde.
A navíc tak uložíš nejdřív Company a pak usera, žejo.

To vede  k architektuře, která z vysoka kálí na takovéto OOP paradigmata: Z User se stane obyčejné POJO, které bude mít dejme tomu závislost na jinačí POJO, a vytvoří se třída DBUtil, která bude pro jejich zpracování.

Celkově se jeví, že ten problém nemáš ani tak s OOP jako s tím, že máš nějakou konkrétní představu o OOP, a tu se snažíš silou mocí protlačit.

Čichá čichám cargo-cult.

1428

Studium a uplatnění / Re:Výběr vhodného OOP jazyka

« kdy: 06. 06. 2018, 15:00:34 »

Dodam este, ze ciste OOP samo o sebe neexistuje, vzdy je niecim "pokazene" a teda ide skor o multiparadigmovy pristup.  Kod moze byt viac objektovo-orientovany, alebo menej-objektovo orientovany podla toho, ake  je programator prasa, alebo ake obmedzenia su kladene na aplikaciu/system. OOP je stavove a stav je v objekte, to bez debaty.

Smalltalk by se do toho nevešel?

1429

Studium a uplatnění / Re:Výběr vhodného OOP jazyka

« kdy: 06. 06. 2018, 03:00:09 »

Python i JavaScript mají typy, nějak se v tom plácáš.

To vykládej někomu, kdo tomu nerozumí.

To evidentně právě dělám.

Že já vždycky těmhle trollům naběhnu...

1430

Vývoj / Re:OOP a pravidla pro konstruktor

« kdy: 05. 06. 2018, 23:05:52 »

Tak já jsem psal, co je lambda z takového toho filozofického hlediska. Jak je to reálně implementováno není to, co jsem řešil a tudíž jsem si to samozřejmě zjednodušil a rozdíl mezi lambdou a uzávěrem jsem zanedbal.

Lambda je jen anonymní funkce. Uzávěr vznikne vhodnou implementací lambdy tak, aby nesl stav.

Nerozumím, proč mi to píšeš.

1431

Studium a uplatnění / Re:Výběr vhodného OOP jazyka

« kdy: 05. 06. 2018, 23:03:23 »

Ovšem polymorfismus, to je něco, na čem OOP stojí a padá - ať už realizovaný na základě zpráv, nebo pomocí generických funkcí (u nichž zase ztrácí smysl zapouzdření, jak ho chápou jazyky jako Java).

Jen pro pořádek, polymorfizmus v haskellu:

Kód: [Vybrat]

format (JSON x) = ...
format (XML x) = ...
format (HTML x) = ...

IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu. Vše ostatní tu bylo, je, a častokrát i líp.

1432

Studium a uplatnění / Re:Výběr vhodného OOP jazyka

« kdy: 05. 06. 2018, 22:56:02 »

Python i JavaScript mají typy, nějak se v tom plácáš.

To vykládej někomu, kdo tomu nerozumí.

1433

Vývoj / Re:OOP a pravidla pro konstruktor

« kdy: 05. 06. 2018, 21:15:02 »

Pokud je mi známo, např. Jávka řeší uzávěry vznikem anonymní funkce při překladu. Smalltalk má na uzávěry instance třídy BlockClosure.
Rozdíl lambdy a uzávěry asi slyšet nechcete...

Tak já jsem psal, co je lambda z takového toho filozofického hlediska. Jak je to reálně implementováno není to, co jsem řešil a tudíž jsem si to samozřejmě zjednodušil a rozdíl mezi lambdou a uzávěrem jsem zanedbal.

Takže pokud máš nějakou pointu z tohoto hlediska...

1434

Studium a uplatnění / Re:Výběr vhodného OOP jazyka

« kdy: 05. 06. 2018, 15:37:41 »

Podobně se statické typování cpe do PHP,  i když ho nepotřebuje.

Optional statické typy jsou věc, která činí PHP výjimečným (v rámci toho, že je to bastl). Říct, že ho nepotřebuje je zoufalé nepochopení vo co de.

Pokud nechápeš typy, tak používej jazyky, které je nemají. Python, nebo Javascript jsou v takovém případě mnohem lepší volbou.

1435

Vývoj / Re:OOP a pravidla pro konstruktor

« kdy: 05. 06. 2018, 14:56:02 »

Tak lambda je defakto ad-hoc objekt bez setterů, mající právě jednu metodu :-) Co si budem povídat, geniální koncept.

To nemusí být vůbec pravdou, záleží na implementaci. Mimoto je docela obvyklým nedostatkem nerozlišovat lambdy a uzávěry.

Bylo by zajímavé, když by si rozvedl rozdíly. Jinak je to o ničem.

1436

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 04. 06. 2018, 20:00:44 »

Tak si myslim, ze mame neshodu v terminologii a nicem jinem.
Tomu cemu ty rikas pitvacni ja rikam unit testy.
Tomu cemu rikas unit testy ja rikam akceptacni (i na urovni testovani jedine metody/funkce).

Snazil jsem se najit pro svou terminologii nejakou solidnejsi oporu ale nenasel jsem. Spis mi prijde, ze terminologie jeste neni ustalena a kazdy si to nazyva jak chce.
Narazil jsem na tohle: https://testing.googleblog.com/2010/12/test-sizes.html
Coz vypada, ze i u google meli v terminologii gulas a tak zavedli uplne "novou": small, medium, large...

Tak může být.

Já jsem se zatím setkal s tím, že programátoři píší testy, kdy testují chování jednotek, to jest tříd, nebo funkcí. Většinou jsme tomu říkali jednotkové testování. JUnit, NUnit, ... Cílem bylo zjistit, zda všechny stavy toho objektu dělají to co chceme. Tím že se to zapíše do testu se navíc toto chování zakonzervuje. V některých jazycích takových testů potřebuješ méně (Haskell), v některých musíš testovat úplně všechno (Javascript, Python).

Pak jsem se setkal s tím, že máš nějakou velkou legaci obludu, a začíná se ti to rozpadat pod rukama. Tak se dělají akceptační testy třeba na web pomocí Selenia. Nebo jsem psal testy na konzolovou aplikaci, což znamenalo, že jsem si testem vytvořil prostředí, spustit apku s vhodnými argumenty, a pak zjišťoval, co vypotila.

Rozdíl oproti těm předchozím je v tom, že jen obtížně pokryješ všechny možné scénáře. Což v legaci kódu už jen pár testů pomůže. A vůbec obecně netestuješ jednu jednotku, ale spíše harmonii všech těch jednotek, které tvoří aplikaci.

Ano, dalo by se uvažovat tak, že ty akceptační jsou vlastně jen ty jednotkové ve větším, protože když testuješ objekt, tak on taky jen deleguje práci na další své závislosti a tak. Rozdíl ale vidím v tom, že nikdo soudný nevytváří objekty v těch objektech ručně, ale předává je jako závislost - tudíž testuješ čistě a pouze interakci toho objektu s těmi závislostmi. A při testech jsou ty závislosti namockované. Zatímco v těch akceptačních testech testuješ, zda skutečně proběhl zápis do databáze, vytvořil se soubor, odeslal se mail. Testuješ, zda proběhnou všechny ty interakce v té hromadě provázaných objektů. V jednotkovém testu testuješ jen zda se správně zeptal té namockované závislosti.

Jak tomu pak říkat, je jiná věc :-)

1437

Vývoj / Re:OOP a pravidla pro konstruktor

« kdy: 04. 06. 2018, 18:59:07 »

Az na to, ze ten Prolog neni funkcionalni... Protoze ne vsechno deklarativni je funkcionalni.

Myslím, že Prolog patří hlavně do kategorie Logických jazyků. Ale spíše také, páč deklarativní je.

1438

Vývoj / Re:OOP a pravidla pro konstruktor

« kdy: 04. 06. 2018, 18:10:45 »

Agresivita je zbytocna, lambdam skor ci neskor podlahnete. Je to elegantne a netreba potom riesit malichernosti s konstruktormi.

Tak lambda je defakto ad-hoc objekt bez setterů, mající právě jednu metodu :-) Co si budem povídat, geniální koncept.

1439

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 04. 06. 2018, 17:07:46 »

Ja nedavam za pravdu anonymum... Jen mi prijde, ze se prilis casto unit testy zamenuji za akceptacni.
Podle me to co popisujes jsou opravdu akceptacni testy. Jednim z poznavacich znaku je i to, ze pokud se nezmeni rozhrani, ale jen implementace tak na akceptacni testy nemusim sahat.

No tak to se má samosebou, ne? Unittesty jsou na tu menší část, akceptační jsou skoro u klienta. Když rozbiješ unit, tak rozbiješ akceptační, když nerozbiješ akceptační, tak jsi nerozbil unit.

Oproti tomu unit testy obvykle zmenit musim i pri zmene implementace (beze zmeny rozhrani). Protoze unit testy by mely opravdu testovat tu implementaci.

Co je myšleno tou implementací?

Mám objekt. Jednotkou testování je tento objekt (přesněji, volání metody, nebo řady metod nad jednou instancí objektu). Proto je to jednotkové testování. Ten objekt mi naparsuje text na 70znakové kousky. Pokud by byla pravda, že unittesty testují, zda ten objekt používá utf8-supported string parser, nebo ne, tak k čemu je mi takový test vlastně dobrý? Se ti nedivím, že je pak nepíšeš.
Naopak, já budu testovat, zda mi zohledňuje ty háčky a čárky. Jestli to dělá pomocí funkce str(), nebo random(), nebo magic() to je mě upřímně šumák. Neřeším, a není důvod řešit. Nepřináší to vůbec žádný užitek.

Akceptační testování je například to, že mám systém, který zpracovává utf8. Bude nám tenhle objekt, který utf8 neumí stačit? (Klidně může, když jsme v té části všechny háčky odstranili.)

Jak vím, zda umí utf8? Podle unittestů, nebo podle toho, že volá funkci str_parser_UTF8()? A jak poznám, že str_parser_UTF8() skutečně umí utf8? A tak dále.

Unittesty testují chování jednotky. Implementace zajímá vývojáře.

Kdysi jsem poslouchal nejaky podcast, ale uz si nevzpomenu jaky. A tam vyvojar vysvetloval, ze v ramci unit testu testuje jaky konkretni typ kolekce je pouzit pro privatni field nejakeho objektu. Byla to nejaka life-critical aplikace (software kardiostimulatoru nebo neco podobneho) a oni pomoci tech unit testu vlastne vynucovali hlubsi zamysleni pri zmene  implementace.  Takze nejaky smysl to asi ma.

Já netvrdím, že se takovéhle pitvační testy nemohou v některých, extrémních případech hodit. Ale nejsou to unittesty, a unittesty nejsou akceptační.
V některých případech je psaní unittestů náročné. A tak se buď napíší akceptační testy, které nejsou důsledné, ale stačí, nebo klidně se napíše takováhle prasárna, pak to sice furt není důsledné, ale alespoň je to otestované.

1440

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 04. 06. 2018, 15:37:54 »

Unit testy - testuji jednotku. tudiz vnitrni implementaci a strukturu testovaneho objektu.
Casto se to plete dohromady.
https://www.lucassaldanha.com/unit-tests-vs-acceptance-tests/

Testují chování implementaci vůči veřejnému rozhraní. Testují, zda se to chová jak bylo domluveno. Ale netestují žádné privátní fieldy, protože to jaksi není veřejné rozhraní, a jaksi to ani nikdy nepoužiješ. Vývojář to kdykoliv může přepsat, privátní fieldy zahodit, privátní pomocné metody sloučit, rozdělit, nebo přepsat, a testy musí stále projít. Protože se nezměnilo chování ale pouze implementace. Od toho ty testy jsou.

Testovat implementaci pro implementaci jaksi nemá smysl, že jo.

Ostatně ten článek neříká nic o tom, že by se mělo testovat privátní fieldy, nebo pitvat třídu, jak si to tu anonym představoval.