Příspěvky

886

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

« kdy: 11. 06. 2018, 23:15:32 »

V takovém případě pro to je zažité jiné názvosloví (persistence, context, ...). Každopádně to jak to popisuješ se mi nelíbí. A jak tě znám, tak dále to s tebou nebudu řešit.

User a Model je v tomto kontextu maďarština. Používat tu výraz model mi tu nedává smysl právě proto, že se tu neopíráš o ty další dvě komponenty.

Já nevím, mě se zdá název Model pro persistenenci docela běžný. Například v javovských Ebeans dědí entita z Model, nikoli z Persistence (pokud se použije Active Record - ebeans umí data mapper  i active record a uživatel si může vybrat). Lehký java ORM framework ActiveJDBC - taky Model. V PHP je Properl ORM - taky Model.

887

Vývoj / Re:Problematika zabezpečení REST rozhraní

« kdy: 11. 06. 2018, 18:07:34 »

Skoro to vypadá, že nechcete řešit problematiku zabezpečení REST rozhraní, ale postěžovat si, jak jsou věci složité  Ta složitost se prostě postupně nabalí a vnikne z toho knihovna nebo framework. Používejte minimalistické frameworky a máte po problému (ale jen dokud vám bude stačit jejich funkčnost).

888

Odkladiště / Re:Lze získat kvalifikovaný elektronický podpis levněji?

« kdy: 10. 06. 2018, 20:25:07 »

O jakém certifikátu mluvíte - pro podpis jakého kódu a kdo ho má pak akceptovat? A proč je o tolik dražší?

Oficiální název je "code signing certificate" a dají se tím podepisova binárky pro Windows (EXE/DLL/SYS/CAB...), Javovské věci, Androidí věci, myslím, že dnes i Apple. Může záležet na knkrétní CA.

Takové certifikáty (resp. podpisy) pak akceptují příslušné operační systémy, takže software je považován za důvěryhodný (což je zrovna u ovladačí Win dosti kruciální).

Cena může být také způsobena tím, že nemám srovnání s tuzemskou CA, protože snad žádná takové certifikáty sama o sobě nevydává (nejblíže mám zkušenosti s Certum v Polsku a ty mi přijdou dosti levné oproti konkurenci a i přátelské k OSS).

Jasně, dík.

889

Odkladiště / Re:kvalifikovaný elektronický podpis -lze nekde (nejak) levneji

« kdy: 10. 06. 2018, 00:21:36 »

Když tu cenu srovnám s nákupem certifikátu pro podpis kódu, tak mi nepřijde jako problém (je cca 5-10x nižší). Způsob oběření identity bude myslím stejný (doklad totožnosti).

Před lety bylo poměrně netriviální ten certifikát pak nainstalovat, ale to už se doufám změnilo.

O jakém certifikátu mluvíte - pro podpis jakého kódu a kdo ho má pak akceptovat? A proč je o tolik dražší?

890

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

« kdy: 08. 06. 2018, 22:17:29 »

...

...jinými slovy ty chlívečky jsou triviální ale ta kompozice až tolik ne (alespoň v problémech reálných aplikací).

891

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

« kdy: 08. 06. 2018, 22:06:39 »

...

Sice souhlasím s Tebou nastíněným kanonickým řešením, jenže debata je tu o tom, jaký je rozdíl mezi

• User.save()
• Lopata.priloz(Uhli)

Rozdil je zrejmy a trivialni.
Lopata je vykonny @Controller, ktery sibuje s hlopou @Entitou Uhli. Ostane proto Spring tak tyto anotace pojmenoval.

V pripade Usera je spravny pristup
UserRegistr.save(User)

Anebo, pro jeste snazsi pochopeni
Noha.nakopni(zadek), tady je hned jasne, ze zadek.nakopniSe(Nohou) je blbost.

Pri objektovem navrhu je proste nutno v danem co je iniciatorem akce a co je objektem (ne v OOP smyslu) teto akce.
A OOP objekt muze klidne v ruznem kontextu zastavat obe role
Ridic.natoc(Volant)
Volant.natoc(Kola)

Tohle jsou trivialni zaklady objektove dekompozice.

Mno objekty jsou oba, ten vas "actor" i ty "tupa data" - a i ty zamozrejme "neco umi" - umi encapsulovane drzet data a pripadne generovat pohledy na jejich interni data.
"actoru" se v terminologii springu rika @Component, ktery se podle pouziti deli na @Controller, @Service a @Repository. Mezi nimi pobihaji proste POJOs, pripadne ORM entity, pripadne jejich kolekce.

A z toho je vidět, že

• Spring skutečně nemá s „původním“ OOP moc společného
• Spring sice poskytne ty chlívečky @Controller, @Service, ..., ale rozdělit objekty do nich a udělat právě tu kompozici musí programátor sám => moc z původní otázky Spring sám o sobě neřeší
• jestli je Lopata actor nebo entita se nedá bez znalosti kontextu říct (jak sám potvrzujete)

Takže se tady nevymýšlí kolo, jen jsme se k té kompozici zatím vůbec nedostali. Nějaký zdroj, jak právně komponovat? „Správně“ samozřejmě v kontextu daného paradigmatu nebo programátorského stylu. Tím bychom se teprve začali věnovat původní tazatelově otázce, IMHO.

892

Software / Re:Vim - stále viditelné záhlaví souboru

« kdy: 08. 06. 2018, 19:35:05 »

Díky za tipy, ale při rozdělení okna se horní část při posouvání na řádku nesynchronizuje se spodní a raději bych volby zadával jako parametry při spuštění Vimu, nebo do konf. souboru. Ale možná bych měl namísto Vimu použít (pro moje účely) vhodnější nástroj...

Příkazy se do konfiguráku dají normálně napsat. Nebo se dají příkazy nabindovat na klávesovou zkratku (příkazem map) - používám většinou funkční klávesy. Nebo se dá vše nastavit ručně příkazama a pak uložit celou session  (příkazem mks) -  zapamatují se otevřené soubory, pozice kurzorů v nich atd. Celou session lze kdykoli načíst a pokračovat v práci (např. -S při spuštění vimu).

893

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

« kdy: 07. 06. 2018, 17:20:53 »

A jak taková metoda send(cíl) zapadá do oblasti zodpovědnosti objektu User? Jak už jsem psal, takových metod může mít objekt stovky – aby vytvořil unikátní identifikátor instance, aby se hezky vypsal, aby se zvalidoval, aby vrátil svou velikost v paměti…

Samozřejmě nijak, pokud budeme mluvit o tom, že je User "entita". Kitovo tvrzení by platilo v případě, že by User byl doménová služba (předpokládám dle původního dotazu nějakou dnešní typickou MVC-like architekturu).

Nejpřesněji to napsal Youda, konkrétně i pro PHP je to IMHO asi nejčistší přístup. Já osobně to často zjednodušuji jen na Entity/Repository/Services. Tady není co vymýšlet :-)

Ono ty stateless instance typu Service mají tu nevýhodu, že tím jak si nemůžeš udělat field tak ti značně roste počet parametrů v metodách, což nevypadá moc pěkně. Ještě jeden problém který s tímto je, vznikne, když metody takto pasuješ na funkce a přesto nemůžeš vrátit více objektů z funkce, než-li jeden, jako to jde třeba v Golang. To vede k využívání způsobu, kdy parametry metody jsou zároveň výstupními parametry.

A nevím ještě čím to je, ale na všech trochu legacy Spring projektech kde jsem dělal, byly ty Service pospojovány do spletité sítě, ve které byla snad spojeno všechno se vším. Lidi tam měli tendenci až moc nerozlišovat jednotlivé třídy problému. Pamatuju si, když byl kolega naštvaný, že vytvářím pro nový komplexní validační check dat (zbytečně) novou Service, místo abych těch 150 řádků kódu přidal do již existující 800 řádkové Service. Takže ani ta Spring architektura není samospásná a když se nad tím nepřemýšlí, bude v tom bordel.

A jsme u toho, že Spring v tom rozdělení kompetencí moc nepomůže. Správný návrh Services a Entit je téma, které neřeší.

894

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

« kdy: 06. 06. 2018, 23:57:08 »

A třeba Spring Roo, Ebeans a další umí Active Record jako alternativu k Data Mapperu. Výhoda je jasná - schová před uživatelem DAO, čímž schová i komplexitu, což patří IMHO k principu zapouzdření.

Tím je současně vymezena i vhodnost Active Record - hodí se tam, kde nepotřebuju mluvit přímo s Data Mapperem. Například u transakcí podle mě už začíná koncept Active Record drhnout.

895

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

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

...

Sice souhlasím s Tebou nastíněným kanonickým řešením, jenže debata je tu o tom, jaký je rozdíl mezi

• User.save()
• Lopata.priloz(Uhli)

Až budeš mít na tohle návod, dej vědět. Sémantický rozdíl tam v principu totiž není. A celá debata  je tu jen a pouze o tom, jak rozdělit kompetence. A k tomu DI ani Spring MVC nic neříká. Ten jenom poskytuje prostředky. A třeba Spring Roo, Ebeans a další umí Active Record jako alternativu k Data Mapperu. Výhoda je jasná - schová před uživatelem DAO, čímž schová i komplexitu, což patří IMHO k principu zapouzdření.

Čili odpověď k věci se bude spíš zabývat kategoriemi objektů (kolekce, entita, proces, manager, blabla...) a pravděpodobně i jazykem (podstatné jméno, přídavné jméno, sloveso) - s cílem formulovat správné programovací věty a najít vodítka a typické role objektů k rozdělení kompetencí. Tomuhle je nejblíž příspěvek BoneFlute https://forum.root.cz/index.php?topic=18704.msg268483#msg268483

(Bohužel tím pádem přijdou na přetřes i návrhové vzory a zde je riziko, že se budou míchat návrhové vzory týkající se věci samotné (kompetencí) s návrhovými vzory, které jenom maskují nedokonalost jazyka (typicky javy). To jen na okraj.)

896

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

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

Co kdyz budu mit v aplikaci dalsi tabulky? Customers, Officers, Managers...
A taky jim chci umet poslat email, ulozit do databaze, vypsat do logu...
Bude mit kazda svou tridu? Kazda metodu save, send, toString?
Budou implementovat stejne rozhrani?
Budou ty proxy umet pracovat se vsemi takovymi tridami? Nebo bude pro kazdy typ jina proxy?

Ano, ano, ano.

Nejsme však omezeni na jednu metodu send(). Ve třídách mívám 3-5 metod s poměrně unifikovanými názvy.

Jo je to validní řešení akorát se asi nehodí všude. Co když nemám k té entitě zdroják? Pak asi budu postupovat opačně, budu mít service která přijme jako parametr tu entitu nebo budu psát  nějaký adaptér. Ve výsledku se mi ten tvůj přístup pak nemusí hodit.

897

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

« kdy: 06. 06. 2018, 22:23:51 »

Důležité je, že se jedná o související funkce, na tom se shodneme. Ale já mám namysli konkrétní implementaci algoritmu, která provede uložení toho objektu User, a ta patří v každém případě jinam! Teprve potom totiž můžu ukládat do databáze, do souboru, nebo třeba do HTML. Právě tento princip např. Active Record porušuje.

V reálu ale ten algoritmus obvykle není implementovány v třídě User, ale je do třídy User zděděný z předka anebo doplněný weavingem (např. v bytekódu). Což už není tak špatné řešení. Můžu mít taky traity a těmi entitu User uschopnit k tomu, aby se uměl uložit do souboru, do databáze, poslat mailem apod. a ani zde nebude ta implementace pomíchaná s entitou. Případně můžu použít vzor dekorátor. Který postup bude dávat smysl bude opět záležet na zbytku aplikace. Zda to je nebo není pravověrné OOP nedokážu říct. IMHO nejhorší z těch variant  bývá dědění, protože je příliš rigidní.

Já bych měl k tomu generování bytekódu trochu výhrady, ale budiž. To dědění bych škrtnul rovnou, ale na té implementaci mimo třídu User se asi shodneme.

Takže když shrneme původní dotaz, celá otázka se redukuje na to, zda implementaci do entity vůbec pustíme a odkud. Některé ORM frameworky umí více způsobů a lze si mezi vybrat. Samotná metoda save u entity není v rozporu s OOP, což ale neznamená, že je vše předem vyřešeno. Tak jako tak bude potřeba vyřešit řadu dilemat :-)

898

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

« kdy: 06. 06. 2018, 22:18:07 »

Ve všech případech to říkám nějaké proxy: database, email, validace, tisk...

Ne, ve všech případech to říkáte objektu User (posíláte mu zprávu „send“). A těžko pokryjete vše, co lze s objektem User dělat, jednou službou send s jedním rozhraním.

Což může být právě vodítko, že kompetence „send“ má jít do jedné třídy a kompetence „save“ do druhé. Musím přemýšlet, zda se nedostávám do problémů, pokud musím psát „sendEmail“ abych to odlišil od „sendPersonalMessage“.

899

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

« kdy: 06. 06. 2018, 22:12:43 »

Jestli ma byt metoda save nebo ne soucasti objektu, je ve velke mire dano, jestli tim bude narusen SRP (single responsibility principle), tj. zda bude objekt mit jednu konkretni odpovednost, nebo ne.

Ano a to je u každé aplikace různé. Navíc se s rozvojem aplikace ta hranice posouvá - co do zodpovědnosti patří a co už ne. Takže se programátor snaží predikovat, na jak dlouho dopředu se vyplatí myslet a hledá optimum mezi složitostí a univerzálností.

900

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

« kdy: 06. 06. 2018, 21:36:13 »

Důležité je, že se jedná o související funkce, na tom se shodneme. Ale já mám namysli konkrétní implementaci algoritmu, která provede uložení toho objektu User, a ta patří v každém případě jinam! Teprve potom totiž můžu ukládat do databáze, do souboru, nebo třeba do HTML. Právě tento princip např. Active Record porušuje.

V reálu ale ten algoritmus obvykle není implementovány v třídě User, ale je do třídy User zděděný z předka anebo doplněný weavingem (např. v bytekódu). Což už není tak špatné řešení. Můžu mít taky traity a těmi entitu User uschopnit k tomu, aby se uměl uložit do souboru, do databáze, poslat mailem apod. a ani zde nebude ta implementace pomíchaná s entitou. Případně můžu použít vzor dekorátor. Který postup bude dávat smysl bude opět záležet na zbytku aplikace. Zda to je nebo není pravověrné OOP nedokážu říct. IMHO nejhorší z těch variant  bývá dědění, protože je příliš rigidní.