Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: magda 24. 06. 2017, 10:35:23
-
Ahoj, připravuju se na zkoušku o OOP a několikrát jsem při shánění dalších informací narazila na webech, že servisní třídy nejsou moc OOP. Jasně, na netu se dá najít všechno a našla bych tam i opak. Ale myslím, že i tady na fóru ten názor občas zazní, tak jsem si říkala, že se zeptám zdejších odborníků přímo ;) Nevidím na nich nic moc špatného a i v projektech jsme je normálně používali, tak nevím.
-
Ahoj, připravuju se na zkoušku o OOP a několikrát jsem při shánění dalších informací narazila na webech, že servisní třídy nejsou moc OOP. Jasně, na netu se dá najít všechno a našla bych tam i opak. Ale myslím, že i tady na fóru ten názor občas zazní, tak jsem si říkala, že se zeptám zdejších odborníků přímo ;) Nevidím na nich nic moc špatného a i v projektech jsme je normálně používali, tak nevím.
Ak myslite "utility classes", alebo "helpers", tak tie ozaj nie su moc objektove. Vyuzivanie "Utility" classes je skor proceduralny pristup. Podla mojho nazoru je si lepsie priznat, ze clovek programuje multiparadigmovo, nez sa usilovat nasilu ciste objektovo.
-
Myslím takové ty NěcoService. Jako je třeba servisní vrstva plná podobných tříd. Možná jsem to jen špatně pochopila.
-
... že servisní třídy nejsou moc OOP ... Nevidím na nich nic moc špatného a i v projektech jsme je normálně používali, tak nevím.
Servisní třídy dokáží dost zamlžit kód, což je proti filosofii čistého OOP. Navíc si tím vynucují použití zbytečných přístupových metod v třídách obsahujících data. Sevisní třídy se blbě mockují, což přináší zbytečné problémy při psaní jednotkových testů. Polymorfismus se u servisních tříd také užívá blbě.
Při používání servisních tříd toho z OOP moc nezbude. Samotné servisní třídy objektové nejsou, je to jen hromada funkcí, kterým se říká "metody". Třída je pak jen převlečený namespace.
-
1) Alespoň formálně OOP jsou. Služba je nějak nainstanciovaný/naparametrizovaný objekt, má svoje data/stav a má nějaké chování.
2) Věcně vzato to moc objektové není, spíš procedurální.
3) Ovšem na tom není nic špatného. A často to poslouží líp než nějaké pokusy o „čistě objektový“ návrh.
-
Myslím takové ty NěcoService. Jako je třeba servisní vrstva plná podobných tříd. Možná jsem to jen špatně pochopila.
Aha, hentie service classy, co sa pouzivaju JEE a podobnych. Bezstavove servisy su proceduralne. Stavove su mackopes, su to objekty ale blbo sa nad nimi robia objektove abstrakcie.
-
Sevisní třídy se blbě mockují, což přináší zbytečné problémy při psaní jednotkových testů.
Taková třída by měla implementovat nějaké rozhraní a ostatní volají to rozhraní, ne konkrétní implementaci. Navíc odkaz na tu instanci by volající třída měla dostat zvenku (ať už ručně setterem nebo automatizovaně přes nějaké DI), což se ti hodí právě při psaní těch jednotkových testů – podstrčíš tam mock místo skutečné implementace a volající kód není potřeba nijak měnit.
Při používání servisních tříd toho z OOP moc nezbude. Samotné servisní třídy objektové nejsou, je to jen hromada funkcí, kterým se říká "metody". Třída je pak jen převlečený namespace.
Můžeš mít víc instancí téže třídy, které jsou odlišně naparametrizované a díky tomu dělají něco jiného.
Pokud je třída někdy v roli jmenného prostoru, tak je to dané spíš tím, že řešená úloha je natolik jednoduchá a není potřeba mít víc instanci – ale ne tím, že by toho ta třída nedokázala víc (nebo daný jazyk nedokázal víc).
-
Můžeš mít víc instancí téže třídy, které jsou odlišně naparametrizované a díky tomu dělají něco jiného.
S tím souhlasím, v tom případě se jedná o plnohodnotný objekt. Takový však nepočítám mezi instance servisních tříd, i když jsou tak někdy pojmenovány.
-
Kit ako uz zaznelo, robis to spatne. Prave naopak, tie servisne triedy sa najlepsie mockuju. Ale zavislosti tiez musia byt interface (okrem POJO). Inak musis pouzivat kadejake spy mocky co sa neodporuca. K tym parametrom - mozes si vytvorit N implementacii pre kazdu kombinaciu parametrov ked chces. Ak su tie parametre final, nie je to jedno?
Bezstavove servisne triedy nepracuju nad zapuzdrenymi datami, preto sa casto nepovazuju za oop. Je to skor nieco ako v C struktura obsahujuca callbacky. Najma v business programovani ide o vycucnutie dat z db, ich spracovanie a preposlanie klientovi (nejake tie formulare). Vacsinou na to netreba ziaden stav (teda zapuzdrovat data) a ak aj treba, nedrzi sa v objekte, ale v nejakom kontexte (ono to je skor kvoli tomu, ze niekto vymyslel, ze to budu singletony). Ale stale sa pouziva polymorfizmus (viac implementacii servis interfacu), implementujuce triedy mozu pouzivat dedenie atd. Proste vec pohladu. Naopak, OOP sa da programovat aj v C, ale nema modifikatory viditelnosti, tak ludia sa budu hadat, ze to nie je oop..
-
Kit ako uz zaznelo, robis to spatne. Prave naopak, tie servisne triedy sa najlepsie mockuju. Ale zavislosti tiez musia byt interface (okrem POJO). Inak musis pouzivat kadejake spy mocky co sa neodporuca. K tym parametrom - mozes si vytvorit N implementacii pre kazdu kombinaciu parametrov ked chces. Ak su tie parametre final, nie je to jedno?
Servisní třídy nepoužívám.
-
Servisní třídy nepoužívám.
To vela vysvetluje :).
-
Servisní třídy nepoužívám.
To vela vysvetluje :).
Čemu vlastně říkáš "servisní třída"?
-
Myslím takové ty NěcoService. Jako je třeba servisní vrstva plná podobných tříd. Možná jsem to jen špatně pochopila.
Servisní třídy (nebo tedy pokud jsem tě dobře pochopil tak Servisy) používám a používám je rád. Dost to zpřehledňuje kód, protože určitá logika je na jednom omezeném a kontrolovatelném místě. Dobře se definuje, co to má dělat. Pohodlně se to testuje. A při inteligentním návrhu se to dá i dobře komponovat. Snadno se s nimi pracuje ve smyslu snadné nahraditelnosti, změnitelnosti, protože zbytečně nerozšiřuje rozhraní aplikace.
Co se týče OOP, tak bych to moc neprožíval. Žádné mainstreamové OOP jazyky OOP nejsou. A co se týče definice OOP, tak si pod tím každý představuje ledacos.
Takže jako odpověď na tvou otázku: V praxi Servisy ano. V teorii (zkouška ve škole) OOP je bordel, a každej jazyk si to dělá po svém. Co člověk, to názor a na Kaye si nikdo nevzpomene.
-
Podle mě jeden o voze a druhý o koze. Skutečně je to hlavně o tom, co se tou servisní třídou vůbec myslí.
-
To tu zas budu perly :D
-
To tu zas budu perly :D
O Perlu se teď nebavíme. Snažíme se dopracovat k tomu, co to jsou servisní třídy a jak souvisí se servisními objekty.
-
Zkusím hádat,
Controller - instance pro každý UI prvek
Session - instance pro každého uživatele
Service - jen jedna instance v aplikaci.
Proto se údajně má zdát, že Service není OOP? Chápu to správně? Protože má jen jednu instanci?
Když spustím vícero aplikací, s tou Service, kde (např.) bude každá obsluhovat jinou databázi, tak to přece už platit nebude.
-
Co se týče OOP, tak bych to moc neprožíval. Žádné mainstreamové OOP jazyky OOP nejsou. [...] a na Kaye si nikdo nevzpomene.
Tři lidi se shodnou na tom, co je OOP, jen když dva z nich jsou mrtví (ne že bych teď nabádal k vraždám). Jenže z pragmatického pohledu jediná důležitá věc je polymorfismus, jehož lze dosáhnout prostými protokoly (rozhraními), zbytek tzv. "OOP" je víceméně k ničemu. Pak jsou ještě technikality jako nějaký automatický způsob správy paměti nebo rozumná podpora paralelismu, ale to už jsme někde jinde. Jakmile se přidají i jen blbá generika, tak už se klouže k FP s tím, že to bude jen polovičatá zkriplená implementace.
P.S. Chudák Kay musí dost trpět, když vidí, kdo dnes píše programy a v čem.
-
Co se týče OOP, tak bych to moc neprožíval. Žádné mainstreamové OOP jazyky OOP nejsou. [...] a na Kaye si nikdo nevzpomene.
Tři lidi se shodnou na tom, co je OOP, jen když dva z nich jsou mrtví (ne že bych teď nabádal k vraždám). Jenže z pragmatického pohledu jediná důležitá věc je polymorfismus, jehož lze dosáhnout prostými protokoly (rozhraními), zbytek tzv. "OOP" je víceméně k ničemu. Pak jsou ještě technikality jako nějaký automatický způsob správy paměti nebo rozumná podpora paralelismu, ale to už jsme někde jinde. Jakmile se přidají i jen blbá generika, tak už se klouže k FP s tím, že to bude jen polovičatá zkriplená implementace.
P.S. Chudák Kay musí dost trpět, když vidí, kdo dnes píše programy a v čem.
A to jsme se ještě nedostali k flame, jak si někteří lide poradí s rozlišování co je otázka OOP a co je otázka Typování.
-
Co se týče OOP, tak bych to moc neprožíval. Žádné mainstreamové OOP jazyky OOP nejsou. [...] a na Kaye si nikdo nevzpomene.
Tři lidi se shodnou na tom, co je OOP, jen když dva z nich jsou mrtví (ne že bych teď nabádal k vraždám). Jenže z pragmatického pohledu jediná důležitá věc je polymorfismus, jehož lze dosáhnout prostými protokoly (rozhraními), zbytek tzv. "OOP" je víceméně k ničemu. Pak jsou ještě technikality jako nějaký automatický způsob správy paměti nebo rozumná podpora paralelismu, ale to už jsme někde jinde. Jakmile se přidají i jen blbá generika, tak už se klouže k FP s tím, že to bude jen polovičatá zkriplená implementace.
P.S. Chudák Kay musí dost trpět, když vidí, kdo dnes píše programy a v čem.
A to jsme se ještě nedostali k flame, jak si někteří lide poradí s rozlišování co je otázka OOP a co je otázka Typování.
OOP bych nechal, to není přesně definované (čímž se možná právě hodí na flame). Těm pár konceptům jako typování, polymorfismus, dědičnost apod. se dá věnovat zvlášť, jsou navzájem ortogonální.
-
A to jsme se ještě nedostali k flame, jak si někteří lide poradí s rozlišování co je otázka OOP a co je otázka Typování.
OOP bych nechal, to není přesně definované (čímž se možná právě hodí na flame). Těm pár konceptům jako typování, polymorfismus, dědičnost apod. se dá věnovat zvlášť, jsou navzájem ortogonální.
Dá. Ale málokomu je to jasné. Mnoho programátorů chápe OOP jako dědičnost + třídy + interface. Tři věci z toho nejsou součástí OOP.
-
Tady na rootu se každá diskuze o OOP nějak zacyklí, nezdá se vám?
-
Tady na rootu se každá diskuze o OOP nějak zacyklí, nezdá se vám?
V OOP i ve FP preferuji spíš rekurzi.
-
A to jsme se ještě nedostali k flame, jak si někteří lide poradí s rozlišování co je otázka OOP a co je otázka Typování.
OOP bych nechal, to není přesně definované (čímž se možná právě hodí na flame). Těm pár konceptům jako typování, polymorfismus, dědičnost apod. se dá věnovat zvlášť, jsou navzájem ortogonální.
Dá. Ale málokomu je to jasné. Mnoho programátorů chápe OOP jako dědičnost + třídy + interface. Tři věci z toho nejsou součástí OOP.
Ono je to definovane. Zakladne principy su - dedicnost, polymorfizmus a enkapsulacia.
To, ze kazdy to chape inac a niekomu sa to nepaci je ina vec. (napriklad mne sa nepaci polymorfizmus a dedicnost)
-
Ono je to definovane. Zakladne principy su - dedicnost, polymorfizmus a enkapsulacia.
To, ze kazdy to chape inac a niekomu sa to nepaci je ina vec. (napriklad mne sa nepaci polymorfizmus a dedicnost)
Těším se, až mnozí programátoři pochopí i princip zapouzdření :-)
-
no ty vole, opet tema ohledne OOP. se poseru. a opet si tu dokazuji nekteri co je a co neni OOP. ja jenom lituji spolupracovniky, kteri to zcela jiste nemaji lehke, kdyz maji v kanclu takoveto individua.
-
Servisní třídy slouží taky k tomu, aby se pokaždé s každým požadavkem nevytvářely znovu ty samé instance tříd, protože by to mělo vliv na performance. Když se dělá se Servisními třídami např ve Springu, je třeba to tak trochu brát jako práci uvnitř návrhového vzoru.
Myslím si, že Service je třeba brát spíše jako nutnost a ne něco, co má nějak vylepšit OOP. Osobně moc Services rád nemám, myslím že třeba v typickém Spring app se docela nadužívají, prostě každá nová třída dostane anotaci buďto Service nebo DAO. To není dobře.
Co se týče samotného OOP, tak odpověď na to, co to je, by se dal brát myslím si ze dvou stran. Ta první, mě bližší: prirozené obohacení procedurálního programování o přimou podporu zapouzdřenosti (tvorba modulů) a polymorfizmu (nad těmito moduly). To je takový praktický pohled na věc. Pak je ještě pohled z druhé strany, tomu se vyhýbám, a to od OOP teoretiků. Tento úhel pohledu nemám rád, protože je přehnaný a dost přesahuje schopnosti samotného OOP. S OOP se nedají modelovat reálné věci, je příliš stupidní. Takže já se držím definice OOP jakožto vylepšení starého způsobu programování a především beru OOP jako nástroj pro programátora, a ne programátora jako nástroj pro OOP.
-
... především beru OOP jako nástroj pro programátora, a ne programátora jako nástroj pro OOP.
Také to tak beru. OOP má programátorovi sloužit a nevytvářet mu "povinnosti". Dědičnost usnadňuje tvorbu podobných modulů, polymorfismus práci s nimi a zapouzdření pomáhá vytvářet moduly s minimálním rozhraním a maximální soběstačnosti.
-
jo Kit jako vzdycky bude rikat jenom to svy. zustan radsi u php.
-
jo Kit jako vzdycky bude rikat jenom to svy. zustan radsi u php.
Jasně, baron nám to vysvětlil mnohem lépe. Jenom mi stále není jasné, jak svůj názor zakomponuješ do svého oblíbeného jazyka, tak, aby to bylo ve stylu OOP.
-
no to neni ani php. kdyz se naucis delat v prologu, lispu, haskellu, fortranu, smalltalku, tak si muzem povidat. jenom takovou praci nesezenes v Praze, musis jit o kus dal usa, nemecko, svycarsko, norsko, holandsko. tam pracuji jine kapacity
-
no to neni ani php. kdyz se naucis delat v prologu, lispu, haskellu, fortranu, smalltalku, tak si muzem povidat. jenom takovou praci nesezenes v Praze, musis jit o kus dal usa, nemecko, svycarsko, norsko, holandsko. tam pracuji jine kapacity
jsi javaman nebo zboj?
-
nejsem nikto z mistnich trollu ;)
-
no to neni ani php. kdyz se naucis delat v prologu, lispu, haskellu, fortranu, smalltalku, tak si muzem povidat. jenom takovou praci nesezenes v Praze, musis jit o kus dal usa, nemecko, svycarsko, norsko, holandsko. tam pracuji jine kapacity
Ve zmíněných jazycích jsem už dělal, tak povídej. Upozorňuji tě však, že práci nehledám, natož v Praze.
-
delal profesionalne? ja v tom delam 20 let, z toho 15 v zahranici
-
delal profesionalne? ja v tom delam 20 let, z toho 15 v zahranici
Ano profesionálně. Do zahraničí se však nijak nehrnu. Nemám důvod.
-
no jo, nekdo sedi doma na zadku a placa nesmysly tady na foru. je mozny, ze jsi jeste nikdy nepotkal poradneho profesionala
-
no jo, nekdo sedi doma na zadku a placa nesmysly tady na foru. je mozny, ze jsi jeste nikdy nepotkal poradneho profesionala
Máš pravdu. Je neděle, venku prší, sedím doma na zadku a plácám nesmysly tady na fóru. Dokonce umím používat háčky a čárky, což lidé v zahraničí moc nezvládají a plácají své nesmysly bez nich.
Povídej, už jsi potkal nějakého profesionála? Jaký jsi měl z toho pocit? Uměl OOP, o kterém se tady bavíme?
-
Povídej, už jsi potkal nějakého profesionála? Jaký jsi měl z toho pocit? Uměl OOP, o kterém se tady bavíme?
Abych nezapomněl: Co si ten tvůj profesionál myslí o servisních třídách v OOP? Vysvětlil ti to?
-
ja potkavam profesionali kazdej den, lidi vazne na urovni.
-
ja potkavam profesionali kazdej den, lidi vazne na urovni.
A co ti říkali o servisních třídách v OOP?
-
Ono je to definovane. Zakladne principy su - dedicnost, polymorfizmus a enkapsulacia.
To, ze kazdy to chape inac a niekomu sa to nepaci je ina vec. (napriklad mne sa nepaci polymorfizmus a dedicnost)
Těším se, až mnozí programátoři pochopí i princip zapouzdření :-)
To aj ja, tie uchylnosti s gettrami a settrami su ako mor. To nie je enkapsulacia.
-
panove vcem delate konkretne vy (jakej jazyk, na jakem projektu)?
-
Ono je to definovane. Zakladne principy su - dedicnost, polymorfizmus a enkapsulacia.
To, ze kazdy to chape inac a niekomu sa to nepaci je ina vec. (napriklad mne sa nepaci polymorfizmus a dedicnost)
Těším se, až mnozí programátoři pochopí i princip zapouzdření :-)
To aj ja, tie uchylnosti s gettrami a settrami su ako mor. To nie je enkapsulacia.
Moje řeč. Bohužel se na ty zrůdné *ettery musím koukat denně a většinou si ani nemohu dovolit je refaktorovat do něčeho rozumnějšího.
-
panove vcem delate konkretne vy (jakej jazyk, na jakem projektu)?
Víš dobře, že dělám v PHP. To sis tady už mohl najít.
-
projekty?
-
panove vcem delate konkretne vy (jakej jazyk, na jakem projektu)?
Smalltalk
-
projekty?
Servisní třídy v OOP. Říká ti to něco?
-
Co je to třída?
-
Co je to třída?
Odporucam wikipediu:
https://en.wikipedia.org/wiki/Class-based_programming
-
Co je kokotizmus? Staci zajit na forum.root.cz a objevite to.
-
Co je kokotizmus? Staci zajit na forum.root.cz a objevite to.
Třeba se od tebe někdy i dozvíme, co jsou to servisní třídy v OOP. Zkus se zeptat svých profesionálů, snad ti poradí.
-
s vama nema vubec vyznam diskutovat. nema to cenu. proto tady vladne kokotizmus.
-
s vama nema vubec vyznam diskutovat. nema to cenu. proto tady vladne kokotizmus.
Omyl, nevládneš tady. Vládne tu téma o servisních třídách v OOP, ke kterým ses dosud nevyjádřil.
-
kazdej at si pouziva co uzna za vhodny. protlacat nekde nasilu cisty OOP je demence. clovek se uci zkusenostmi a praxi. je hodne teoretiku, kteri nejsou v praxi pouzitelni.
-
kazdej at si pouziva co uzna za vhodny. protlacat nekde nasilu cisty OOP je demence. clovek se uci zkusenostmi a praxi. je hodne teoretiku, kteri nejsou v praxi pouzitelni.
Také je hodně praktiků, po kterých zůstává hromada WTF, protože nesnášeli teorii.
-
teoretici vetsinou zustanou na skole ucit tu teorii az do zestarnuti. v praxi jsou ale nepouzitelni. znam jednoho PhD strojare, ktery mi rikal, ze svaret umi, ale nesvari, zna teorii, postupy a tak dale, o kterych mozna vyklada na prednaskach :D. No dal bys mu udelat neco?
-
teoretici vetsinou zustanou na skole ucit tu teorii az do zestarnuti. v praxi jsou ale nepouzitelni. znam jednoho PhD strojare, ktery mi rikal, ze svaret umi, ale nesvari, zna teorii, postupy a tak dale, o kterych mozna vyklada na prednaskach :D. No dal bys mu udelat neco?
Určitě bych tě nenechal dělat servisní třídu v OOP.
-
ja bych tobe nedal udelat ani "hello world". ;)
-
ja bych tobe nedal udelat ani "hello world". ;)
Pozdě: https://www.itnetwork.cz/nezarazene/programovaci-jazyky-rychlost-spusteni-aplikace (https://www.itnetwork.cz/nezarazene/programovaci-jazyky-rychlost-spusteni-aplikace)
-
Co je to třída?
Odporucam wikipediu:
https://en.wikipedia.org/wiki/Class-based_programming
To já samozřejmě znám, ale nějak mi nejde přes pysky "servisní třídy". Rozuměl bych "servisním objektům". V programu totiž třída ztrácí smysl, je to jen pouhá šablona layoutu výsledného objektu a nějakých drobností kolem (jako tabulka vt)
-
Pozdě: https://www.itnetwork.cz/nezarazene/programovaci-jazyky-rychlost-spusteni-aplikace (https://www.itnetwork.cz/nezarazene/programovaci-jazyky-rychlost-spusteni-aplikace)
kde mas C#? lidi chteji taky C#, viz. komentare. Jo to ty neumis! Ono PHP je sracka, nevim ve ktery zaprdeny firme jeste v tom delaji. Jses zaspal dobu nebo co? Java nebo C# budou mozna pomalejsi, jenomze vyvoj bude rychlejsi a snadnejsi nez v PHP ;). Dnes se moc na rychlost nehraje a nesnaz se namluvit, ze delas v PHP pro embedded zarizeni :D
-
Pozdě: https://www.itnetwork.cz/nezarazene/programovaci-jazyky-rychlost-spusteni-aplikace (https://www.itnetwork.cz/nezarazene/programovaci-jazyky-rychlost-spusteni-aplikace)
kde mas C#? lidi chteji taky C#, viz. komentare. Jo to ty neumis! Ono PHP je sracka, nevim ve ktery zaprdeny firme jeste v tom delaji. Jses zaspal dobu nebo co? Java nebo C# budou mozna pomalejsi, jenomze vyvoj bude rychlejsi a snadnejsi nez v PHP ;). Dnes se moc na rychlost nehraje a nesnaz se namluvit, ze delas v PHP pro embedded zarizeni :D
Když jsem psal ten článek, tak byl C# teprve v začátcích a byl docela minoritní. Později jsem sice udělal totéž pro Mono, ale do článku jsem to už doplnit nemohl. Nemám však důvod dělat v C#, aplikace se stejně nedá přeložit do nativního kódu. Z mého pohledu je ten jazyk dost mimo, protože usnadňuje vývojářům nežádoucí konstrukce a naopak jsou v něm některé žádané konstrukce dost obstruktivní.
A co ty tvé servisní třídy (resp. správněji servisní objekty)? Už jsi nějaké napsal?
-
Neda prelozit do nativniho kodu? Ty jsi snad delas zadek! Rika ti neco .net native toolchain? Komentare jsou z roku 2013, C# existuje jiz pekne dlouho, nekdy od 2002. Uz ve 2013 byl o hodne dal nez php ;).
-
Čudujem sa že na toho PHPčkarskeho tro(t)lla vôbec reagujete.
-
To já samozřejmě znám, ale nějak mi nejde přes pysky "servisní třídy". Rozuměl bych "servisním objektům". V programu totiž třída ztrácí smysl, je to jen pouhá šablona layoutu výsledného objektu a nějakých drobností kolem (jako tabulka vt)
Pozor, tohle rozhodně neplatí o všech jazycích. Ve slušném objektovém systému je třída také normální entita (objekt).
To je samozřejmě offtopic.
-
Neda prelozit do nativniho kodu? Ty jsi snad delas zadek! Rika ti neco .net native toolchain? Komentare jsou z roku 2013, C# existuje jiz pekne dlouho, nekdy od 2002. Uz ve 2013 byl o hodne dal nez php ;).
Matlat něco v C# by se mi vážně nechtělo. Proč taky? Existuje přece hromada lepších jazyků, alespoň z mého pohledu. Pokud jsem si správně všiml, tak .NET Native Toolchain generuje pouze EXE a DLL. To moc nativně nezní. Co třeba ELF?
PHP je moderním objektovým jazykem, ale nikomu ho nevnucuji. Pište si své programy v čem chcete.
-
To já samozřejmě znám, ale nějak mi nejde přes pysky "servisní třídy". Rozuměl bych "servisním objektům". V programu totiž třída ztrácí smysl, je to jen pouhá šablona layoutu výsledného objektu a nějakých drobností kolem (jako tabulka vt)
Pozor, tohle rozhodně neplatí o všech jazycích. Ve slušném objektovém systému je třída také normální entita (objekt).
O důvod víc, proč tomu říkat raději "servisní objekt" nebo ve větším měřítku "servisní vrstva".
-
To já samozřejmě znám, ale nějak mi nejde přes pysky "servisní třídy". Rozuměl bych "servisním objektům". V programu totiž třída ztrácí smysl, je to jen pouhá šablona layoutu výsledného objektu a nějakých drobností kolem (jako tabulka vt)
Pozor, tohle rozhodně neplatí o všech jazycích. Ve slušném objektovém systému je třída také normální entita (objekt).
To je samozřejmě offtopic.
Takových jazyků ale moc není (bohužel). Z čistě pragmatického pohledu to ani moc nutné není, jsou důležitější vlastnosti.
-
Neda prelozit do nativniho kodu? Ty jsi snad delas zadek! Rika ti neco .net native toolchain? Komentare jsou z roku 2013, C# existuje jiz pekne dlouho, nekdy od 2002. Uz ve 2013 byl o hodne dal nez php ;).
Matlat něco v C# by se mi vážně nechtělo. Proč taky? Existuje přece hromada lepších jazyků, alespoň z mého pohledu. Pokud jsem si správně všiml, tak .NET Native Toolchain generuje pouze EXE a DLL. To moc nativně nezní. Co třeba ELF?
PHP je moderním objektovým jazykem, ale nikomu ho nevnucuji. Pište si své programy v čem chcete.
Co jiného by měl produkovat? Jeho výstupem je nativní binárka na stroji s Windows OS. Jen ten kompilátor není multiplatformní. Popravdě dlouho jsem o tom zas neslyšel, ale jak koukám třeba na Scalu a Kotlin, začíná to být populární -- kromě dnes časté transpilace do JS.
-
To já samozřejmě znám, ale nějak mi nejde přes pysky "servisní třídy". Rozuměl bych "servisním objektům". V programu totiž třída ztrácí smysl, je to jen pouhá šablona layoutu výsledného objektu a nějakých drobností kolem (jako tabulka vt)
Pozor, tohle rozhodně neplatí o všech jazycích. Ve slušném objektovém systému je třída také normální entita (objekt).
O důvod víc, proč tomu říkat raději "servisní objekt" nebo ve větším měřítku "servisní vrstva".
Svata prostoto. To, ze sa Magda nevie vyjadrovat jednoznacne a neupresnila programovaci jazyk, nechame bokom, ale ak Magda v oboch svojich prispevkoch spomenula podstatne meno zenskeho rodu trieda, myslite si, ze hovorila o implementacii sluzieb (v najsirsom slova zmysle) v:
a) prototypovom jazyku
b) pure funkcionalnom jazyku
c) class based jazyku (cough, cough, trieda) <--------------------- SPRAVNA ODPOVEDtm
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
...makes you wonder.
-
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
V class based jazyku musíš vytvořit třídu, v ostatních nemusíš. Výsledkem je v obou případech servisní objekt.
-
To já samozřejmě znám, ale nějak mi nejde přes pysky "servisní třídy". Rozuměl bych "servisním objektům". V programu totiž třída ztrácí smysl, je to jen pouhá šablona layoutu výsledného objektu a nějakých drobností kolem (jako tabulka vt)
Pozor, tohle rozhodně neplatí o všech jazycích. Ve slušném objektovém systému je třída také normální entita (objekt).
O důvod víc, proč tomu říkat raději "servisní objekt" nebo ve větším měřítku "servisní vrstva".
Svata prostoto. To, ze sa Magda nevie vyjadrovat jednoznacne a neupresnila programovaci jazyk, nechame bokom, ale ak Magda v oboch svojich prispevkoch spomenula podstatne meno zenskeho rodu trieda, myslite si, ze hovorila o implementacii sluzieb (v najsirsom slova zmysle) v:
a) prototypovom jazyku
b) pure funkcionalnom jazyku
c) class based jazyku (cough, cough, trieda) <--------------------- SPRAVNA ODPOVEDtm
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
...makes you wonder.
S termínem servisní třída mám problém, protože ho neznám. Pokud jde o nějakou knihovnu bezstavových operací, tak spíš než třídu používám normální namespace. Chápu tedy, že v jazycích, které nemají namespace musím toto zabalit do třídy. Tomu bych rozuměl.
To co já nazývám servisními objekty, nebo často servisními interfacemi jsou objekty/interface, které obsahují hromadu metod, které spolu moc nemusí souviset, některé jsou stavové, jiné bezstavová, často jsou tam továrny. Zahrnutí do interface má ten význam, že skrývám implementaci, buď proto, že nechci aby byla vidět, nebo většinou proto, že v tom místě není definována (je dodána později). To třeba umožňuje nahradit skutečnou implementaci mockupem.
Servisní objekt skrze interface se buď předává do funkčních objektů přes konstruktor, někdy je dodáván později, někdy se dá za běhu změnit, záleží na typu objektu. Někdy jej mám globální nebo thread lokální, pokud jde o něco hodně základního. Třeba logovací service je zpravidla thread lokální, abych služby logování měl k dispozici všude a abych si nemusel logovací objekt předávat mezi objekty do zblbnutí.
Thread lokální objekty nadále neztrácí možnost funkcionalitu dočasně změnit, třeba v rámci následujícího volání mohu chtít změnit logovacího objektu, a po návratu z vrátím stav služby do původního stavu.
-
A ještě doplnění. v jazycích s třídami předpokládám, že
objekt = instance třídy
-
To co já nazývám servisními objekty, nebo často servisními interfacemi jsou objekty/interface, které obsahují hromadu metod, které spolu moc nemusí souviset, některé jsou stavové, jiné bezstavová, často jsou tam továrny. Zahrnutí do interface má ten význam, že skrývám implementaci, buď proto, že nechci aby byla vidět, nebo většinou proto, že v tom místě není definována (je dodána později). To třeba umožňuje nahradit skutečnou implementaci mockupem.
Takže servisní interface = fasáda?
-
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
V class based jazyku musíš vytvořit třídu, v ostatních nemusíš. Výsledkem je v obou případech servisní objekt.
OK, tak dufam Sherlock, ze teraz je uz vyznam spojenia "servisna trieda" jasny.
Apropo tie ostatne jazyky, ktorym ste sa tak laskavo vyhli.. ci to nahodou nebude tak, ze v ostatnych jazykoch existuju ine prostriedky na odizolovanie concernov. Napriklad si neviem celkom predstavit, kto by potreboval servisy vo funkcionalnych jazykoch a na co a co by to vlastne bolo, keby to nebol "objekt", ze.
Etymologicke okienko:
Namiesto "servisneho objektu" vam odporucam osvojit si spojenie "instancia servisu". Je to prenositelne medzi domenami aj jazykmi a implikuje to jedinecnost a temporalnost bez silnej vazby na objektovo orientovane programovanie.
Kolegovia vam podakuju - ja by som napriklad za spojenie "servisny objekt" fackal, ale ako som uz spominal pri inej teme, studoval som prirodzene jazyky, tak mam taky lahky fetish.
-
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
V class based jazyku musíš vytvořit třídu, v ostatních nemusíš. Výsledkem je v obou případech servisní objekt.
OK, tak dufam Sherlock, ze teraz je uz vyznam spojenia "servisna trieda" jasny.
Apropo tie ostatne jazyky, ktorym ste sa tak laskavo vyhli.. ci to nahodou nebude tak, ze v ostatnych jazykoch existuju ine prostriedky na odizolovanie concernov. Napriklad si neviem celkom predstavit, kto by potreboval servisy vo funkcionalnych jazykoch a na co a co by to vlastne bolo, keby to nebol "objekt", ze.
Etymologicke okienko:
Namiesto "servisneho objektu" vam odporucam osvojit si spojenie "instancia servisu". Je to prenositelne medzi domenami aj jazykmi a implikuje to jedinecnost a temporalnost bez silnej vazby na objektovo orientovane programovanie.
Kolegovia vam podakuju - ja by som napriklad za spojenie "servisny objekt" fackal, ale ako som uz spominal pri inej teme, studoval som prirodzene jazyky, tak mam taky lahky fetish.
Bavíme se o objektových jazycích - neměl jsem důvod do toho zahrnovat funkcionální.
Servisní třídy obvykle nedávají smysl, protože v takových bývá jen hromada nesouvisejících funkcí. Nevidím důvod, proč by taková hromada měla být v jedné třídě. Dá se pochopit třída Math, ale takových tříd moc není.
-
To já samozřejmě znám, ale nějak mi nejde přes pysky "servisní třídy". Rozuměl bych "servisním objektům". V programu totiž třída ztrácí smysl, je to jen pouhá šablona layoutu výsledného objektu a nějakých drobností kolem (jako tabulka vt)
Pozor, tohle rozhodně neplatí o všech jazycích. Ve slušném objektovém systému je třída také normální entita (objekt).
O důvod víc, proč tomu říkat raději "servisní objekt" nebo ve větším měřítku "servisní vrstva".
Svata prostoto. To, ze sa Magda nevie vyjadrovat jednoznacne a neupresnila programovaci jazyk, nechame bokom, ale ak Magda v oboch svojich prispevkoch spomenula podstatne meno zenskeho rodu trieda, myslite si, ze hovorila o implementacii sluzieb (v najsirsom slova zmysle) v:
a) prototypovom jazyku
b) pure funkcionalnom jazyku
c) class based jazyku (cough, cough, trieda) <--------------------- SPRAVNA ODPOVEDtm
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
...makes you wonder.
S termínem servisní třída mám problém, protože ho neznám. Pokud jde o nějakou knihovnu bezstavových operací, tak spíš než třídu používám normální namespace. Chápu tedy, že v jazycích, které nemají namespace musím toto zabalit do třídy. Tomu bych rozuměl.
To co já nazývám servisními objekty, nebo často servisními interfacemi jsou objekty/interface, které obsahují hromadu metod, které spolu moc nemusí souviset, některé jsou stavové, jiné bezstavová, často jsou tam továrny. Zahrnutí do interface má ten význam, že skrývám implementaci, buď proto, že nechci aby byla vidět, nebo většinou proto, že v tom místě není definována (je dodána později). To třeba umožňuje nahradit skutečnou implementaci mockupem.
Servisní objekt skrze interface se buď předává do funkčních objektů přes konstruktor, někdy je dodáván později, někdy se dá za běhu změnit, záleží na typu objektu. Někdy jej mám globální nebo thread lokální, pokud jde o něco hodně základního. Třeba logovací service je zpravidla thread lokální, abych služby logování měl k dispozici všude a abych si nemusel logovací objekt předávat mezi objekty do zblbnutí.
Thread lokální objekty nadále neztrácí možnost funkcionalitu dočasně změnit, třeba v rámci následujícího volání mohu chtít změnit logovacího objektu, a po návratu z vrátím stav služby do původního stavu.
Nespomenuli ste uz len visitora.
Pri servise nejde o bezstavovost - zakladnym charakterom servisu je vytiahnutie concernu (v zmysle odizolovat starost) do nejakej ciastkovej, samostatne uchopitelnej, pochopitelnej a manazovatelnej (zlyhatelnej) jednotky, co samo sebou nejaky ten stav implikuje. Viete, ako ked si firma najme upratovaci servis alebo si spustite nginx na serveri. Ak je nieco bezstavove a nezlyhatelne, tak by som to nazval funkcia a nech je trebars aj v tom vasom namespace.
Myslim si, ze Magda hovorila o konkretnom jazyku a konkretnom sposobe implementacie servisov v nom prostrednictvom tried.
Ale ved kludne napiste aky privlastok by ste pouzili pre triedu, ktora popisuje implementaciu servisu, ktory by mal mat nejaky ten stavicek a mal by riesit nejaky konkretny concern a pristupovali by ste k nemu cez interface.
-
Myslim si, ze Magda hovorila o konkretnom jazyku a konkretnom sposobe implementacie servisov v nom prostrednictvom tried.
O kterém jazyku?
-
Myslim si, ze Magda hovorila o konkretnom jazyku a konkretnom sposobe implementacie servisov v nom prostrednictvom tried.
O kterém jazyku?
O takom, kde sa na implementaciu servisov pouzivaju triedy. Je to vidiet tu (https://forum.root.cz/index.php?topic=15753.msg216499#msg216499) a tu (https://forum.root.cz/index.php?topic=15753.msg216502#msg216502).
-
Pri servise nejde o bezstavovost - zakladnym charakterom servisu je vytiahnutie concernu (v zmysle odizolovat starost) do nejakej ciastkovej, samostatne uchopitelnej, pochopitelnej a manazovatelnej (zlyhatelnej) jednotky, co samo sebou nejaky ten stav implikuje. Viete, ako ked si firma najme upratovaci servis alebo si spustite nginx na serveri. Ak je nieco bezstavove a nezlyhatelne, tak by som to nazval funkcia a nech je trebars aj v tom vasom namespace.
Celkem pěkná definice.
-
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
V class based jazyku musíš vytvořit třídu, v ostatních nemusíš. Výsledkem je v obou případech servisní objekt.
Nevim jiste, jestli je to ten pripad o kterem se bavite, ale treba ve Scale se trida nutne explicitne nevytvari, programator vytvari "object" a to je uz ta instance (tridu za nej vytvori prekladac).
-
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
V class based jazyku musíš vytvořit třídu, v ostatních nemusíš. Výsledkem je v obou případech servisní objekt.
Nevim jiste, jestli je to ten pripad o kterem se bavite, ale treba ve Scale se trida nutne explicitne nevytvari, programator vytvari "object" a to je uz ta instance (tridu za nej vytvori prekladac).
Iste, aj v notoricky ukecanom triedovom jazyku Džavá, ktory tiez bezi na JVM, mozete mat anonymne triedy, ktore za vas dogeneruje kompiler.
Alebo este lepsie, pokial je vas servis vyjadritelny rozhranim s jednou metodou - je to tzv. SAM (single abstract method) rozhranie, tak cela implementacia takehoto servisu v Džavé moze byt vyjadrena jednou jedinou lambdou. V takom pripade kompiler dokonca ani triedu nevytvori. To sa odlozi na neskor a triedu vytvori Džavá az pri incializacii lambdy v bootstrap metode cez ASM kniznicu pocas runtime. Kazdopadne, konkretna trieda vznike a vznike aj najmenej jedna instancia lambdy (podla toho ci je bezstavova alebo potrebuje pristupovat do lexikalneho scope triedy v ktorej bola zadeklarovana a ci pristupuje k statickym alebo instancnym fieldom).
Som zvedavy ako by lokalni puristi nazvali implementaciu servisu cez lambdu. Servisna lambda? Ked pouzijete spojenie "instancia servisu", je vam jedno ci bol naimplementovany pomocou neanonymnej alebo anonymnej triedy alebo lambdy, ci je to lokalna instancia alebo bezi na druhej strane zemegule v Ruby a vy s nim komunikujete cez nejaky proxy po sieti.
Preto si myslim, ze Magda spojenim "servisna trieda" myslela konkretny jazyk a konkretny sposob implementacie servisov v nom. Jediny problem je, ze neuviedla, ktory jazyk.
Tak na 87% si myslim, ze Magda myslela Javu a Springovu aplikaciu s triedami anotovanymi @Service.
-
A teraz mi prosim vysvetlite, ako inak sa da v class based jazyku vytvorit "servisny objekt" bez tej "servisnej triedy", ktora je "jen pouhá šablona" s jeho implementaciou?
V class based jazyku musíš vytvořit třídu, v ostatních nemusíš. Výsledkem je v obou případech servisní objekt.
Nevim jiste, jestli je to ten pripad o kterem se bavite, ale treba ve Scale se trida nutne explicitne nevytvari, programator vytvari "object" a to je uz ta instance (tridu za nej vytvori prekladac).
Iste, aj v notoricky ukecanom triedovom jazyku Džavá, ktory tiez bezi na JVM, mozete mat anonymne triedy, ktore za vas dogeneruje kompiler.
Alebo este lepsie, pokial je vas servis vyjadritelny rozhranim s jednou metodou - je to tzv. SAM (single abstract method) rozhranie, tak cela implementacia takehoto servisu v Džavé moze byt vyjadrena jednou jedinou lambdou. V takom pripade kompiler dokonca ani triedu nevytvori. To sa odlozi na neskor a triedu vytvori Džavá az pri incializacii lambdy v bootstrap metode cez ASM kniznicu pocas runtime. Kazdopadne, konkretna trieda vznike a vznike aj najmenej jedna instancia lambdy (podla toho ci je bezstavova alebo potrebuje pristupovat do lexikalneho scope triedy v ktorej bola zadeklarovana a ci pristupuje k statickym alebo instancnym fieldom).
Som zvedavy ako by lokalni puristi nazvali implementaciu servisu cez lambdu. Servisna lambda? Ked pouzijete spojenie "instancia servisu", je vam jedno ci bol naimplementovany pomocou neanonymnej alebo anonymnej triedy alebo lambdy, ci je to lokalna instancia alebo bezi na druhej strane zemegule v Ruby a vy s nim komunikujete cez nejaky proxy po sieti.
Preto si myslim, ze Magda spojenim "servisna trieda" myslela konkretny jazyk a konkretny sposob implementacie servisov v nom. Jediny problem je, ze neuviedla, ktory jazyk.
Tak na 87% si myslim, ze Magda myslela Javu a Springovu aplikaciu s triedami anotovanymi @Service.
Instance třídy může být klidně funkce (zvlášť názorné to je u funktorů v C++) a naopak funkce (lambda výraz) si může držet kontext, čímž se chová jako instance třídy. Na ani ne moc abstraktní úrovni jde o jednu věc se dvěma názvy (a úhly pohledu). "Servisní" pak znamená třeba pomocná nebo "nepasuje do hierarchie". Nevím, proč se v tom hledá věda.
-
Nevím, proč se v tom hledá věda.
Asi preto, ze vas vyrok si moze dovolit povedat iba clovek z akademickeho prostredia, ktory sa tomu ako vede venuje a vie ho obhajit?
-
Nevím, proč se v tom hledá věda.
Asi preto, ze vas vyrok si moze dovolit povedat iba clovek z akademickeho prostredia, ktory sa tomu ako vede venuje a vie ho obhajit?
Mně to přijde spíš jako řemeslo a v tomto případě je to diskuze analogická tomu, kolik andělů může tancovat na špičce jehly. Pojem servisní třída není nijak přesně definován, nanejvýš v rámci nějaké knihovny, kde si kdejaký Pepa může z prstu vycucat nic neříkající definici.
-
Nevím, proč se v tom hledá věda.
Asi preto, ze vas vyrok si moze dovolit povedat iba clovek z akademickeho prostredia, ktory sa tomu ako vede venuje a vie ho obhajit?
Mně to přijde spíš jako řemeslo a v tomto případě je to diskuze analogická tomu, kolik andělů může tancovat na špičce jehly. Pojem servisní třída není nijak přesně definován, nanejvýš v rámci nějaké knihovny, kde si kdejaký Pepa může z prstu vycucat nic neříkající definici.
Velmi pekna metafora.