Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: ondra.novacisko.cz 03. 11. 2010, 21:38:52
-
Zdar.
Jakákoliv diskuze o OOP vždycky skončí s flame mezi zastánci třech směrů. Ty s těmi co rozhodně OOP nemusí, těmi, kteří OOP jedině čisté a těmi, co si vystačí s běžnými implementaci OOP, tedy C++, Java, C# a třeba klidně i Visual Basic.
Nejvíc mě ovšem dojímá kritika C++, že není objektový jazyk a jako příklad se uvádí Java, která je koncipována naprosto shodně jako C++. Smaltalkisté se vůbec rádi pouští do C++ a ty ostatní jazyky jako by přehlíželi.
co si o tom myslíte? (ať flame začne v samostatném vlákně)
-
A ze všecho nejhorší jsou trpaslíci.
:D
PS: Hlavne tí v kóde.
-
Jsem pro OOP. A jsem proti C++, protože nemá automatický garbage collector (explicitní používání pointerů je hnus) a místo toho nutí používání destruktorů, což je pro větší aplikace příšerné. Java je v tom oproti C++ mnohem lepší, i když primitivní datové typy v ní dělají zmatek - kdysi to mohlo být výhodné kvůli optimalizaci výkonu, ale design jazyka tím velmi trpí. C# chápu jako reimplementaci Javy od Microsoftu která de facto nefunguje jinde než v MS Windows, pročež si raději vystačím s Javou, i přesto že C# je navržený lépe než Java (je znát že se poučil z jejich chyb).
-
Ja nejsem zastancem OOP. Duvodu mam nekolik:
1. Na spoustu veci je to lopata na komara; jsem priznivec multiparadigmatickeho programovani, ala Python nebo Common Lisp.
2. Libi se mi objektovy model v Common Lispu, zejmena genericke funkce. Oddelenim metod od objektu ziskate moznosti, ktere se v ostatnich OOP jazycich realizuji jen tezko. Stavet programovaci jazyk na uzaverech je daleko jednodussi nez ho stavet na tridach.
3. Nesmyslnost snahy napasovat vsechno na objektovy model sveta vystihl Steve Yegge ve svem blogpostu http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html (http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html).
4. Tridy casto brani efektivnimu programovani, protoze urcuji datovou strukturu, a ta urcuje algoritmy, ktere muzete pouzit. Neni nahoda, ze existuje diskrepance mezi OOP a treba relacnim modelem.
Na nektere ulohy je ovsem OOP naprosto skvela vec. Napriklad GUI. Ale to je specificka situace, kdy objektovost a hierarchicnost vychazi jasne z logiky veci.
-
Jeste jsem chtel zminit tento odkaz, protoze naprosto neni zrejme, co se mysli pod OOP: http://paulgraham.com/reesoo.html (http://paulgraham.com/reesoo.html)
-
Když víš, že zastánci různých směrů se neshodnou a je z toho vždycky akorát flame, tak proč s tím otravuješ?
-
A co to přesně je OOP programování?
Ve všech těch zmiňovaných diskusích (a zatím i v této) se tím míní jakási charakteristická vlastnost programovacch jazyků, podle které se dají porovnávat.
Takto pojatá diskuse samozřejmě skončí jako flamewar a nemá v podstatě žádný smysl.
Jo, pokud by se jednalo o paradigma, tak to je něco úplně jiného.
-
Nejvíc mě ovšem dojímá kritika C++, že není objektový jazyk
Tak to rozhodně nejsi sám, viz např. klasika http://www.ocs.cz/text/Java - ani velký Miroslav Virius to nepobral :)
-
- OOP a garbage collector jsou naprosto nesouvisející věci
- OOP neznamená třídní dědičnost. To je jedna z možných implementací, mající své výhody i svoje limity
- objektově lze psát v každém jazyku, liší se jen míra komfortu (poskytnutých vlastností, které ulehčují často prováděné obraty)
- objektově imho chtě nechtě musí psát každý, neboť je to přirozená organizace kódu (a je úplně jedno, jestli se to v jazyku píše strpos(retezec, znak), nebo retezec.pos(znak) nebo...., to je jen syntaktický cukr. Samozřejmě uvnitř objektů se používá jiné paradigma (většinou procedurální, anebo i funkcionální), ale to je věc s tím v podstatě nesouvisející.
-
Objektové programování je nástroj a jako takový může pomoci spoustu problémů řešit a spoustu jich naopak přinést. Existují různé přístupy k řešení problémů, které OOP pomáhá zvládat, např. takový Haskell se bez OOP obejde úplně a troufám si tvrdit, že minimálně s některými problémy si dokáže poradit i lépe.
Co vlastně OOP pomáhá řešit? Například:
1. Udržování pořádku ve jmenném prostoru (aby se nekřížily identifikátory apod.). Tohle řeší ale i moduly nebo jmenné prostory (namespace např. v C++).
2. Znovupoužitelnost kódu (v OOP pomocí dědičnosti). To se dá řešit různě, například pomocí funkcí vyššího řádu. To je možné i v obyčejném C (qsort apod.).
3. Kontrola přístupu k datům. Tady OOP řeší problém, který přineslo imperativní programování obecně (používáme pořád v podstatě Turingův stroj, který pracuje na úrovni, která je nevhodná pro řešení složitějších úloh). Pokud není člověk prase a ke každé datové položce hned nepíše getter a setter, může být OOP dobré řešení. Na druhou stranu výsledek může být snadno horší, než v obyčejném C, pokud v tom C nedochází k používání globálních proměnných.
4. Poskytnutí vhodné abstrakce pro modelování aplikace (UML). Existují jiné modelovací přístupy, ale UML (včetně class diagramů) class podle mě není špatná věc.
Hlavní problém OOP vidím v tom, že povzbuzuje programátory k tomu, aby pracovali s uloženým stavem (existence datových atributů objektu nebo třídy). Někdy je stav nevyhnutelný, ale v ideálním případě by bylo nejlepší se mu úplně vyhnout (referenční integrita).
-
Pokud není člověk prase a ke každé datové položce hned nepíše getter a setter
A pokud používá moderní jazyk, který umí dekorátory, tak je ani nemusí psát :)
4. Poskytnutí vhodné abstrakce pro modelování aplikace (UML). Existují jiné modelovací přístupy, ale UML (včetně class diagramů) class podle mě není špatná věc.
Má vůbec UML nějakou srovnatelnou konkurenci? ("srovnatelnou" myslím hlavně s podobnou expresivností, univerzálností, existencí široce podporovaného otevřeného formátu, exportem i importem přímo z/do kódu apod.)
Hlavní problém OOP vidím v tom, že povzbuzuje programátory k tomu, aby pracovali s uloženým stavem (existence datových atributů objektu nebo třídy). Někdy je stav nevyhnutelný, ale v ideálním případě by bylo nejlepší se mu úplně vyhnout (referenční integrita).
To je sice hezká teorie, ale v praxi je to myslím celkem nedosažitelné nebo samo o sobě tak těžké, že ve výsledku neefektivní. Kdo někdy zkoušel napsat normální aplikaci (ne nějakou cvičební úlohu) v haskellu nebo prologu, asi ví, o čem mluvím.
-
Ludom, ktory si proti C++ vramci OOP, lebo nepodporuje garbage collector by som odkazal na vyroka pana Stroustrupa: „C++ is my favourite garbage-collected language because it produces so little garbage.“
Neviem, cakal som, ze tu budu ludia s otvorneu myslou, byt proti niecomu oko OOP mi hodne zabednene. Najradsej vidim prispevky, ktore vravia, ze C++ uz je na nic, lebo je dnes Java/C#. Je smutne, ze z celej oblasti programovania vidia iba tu svoju bodku vo vesmire... Ved si len pozrite pracovne ponuky na C++ casto s dvojnasobnymi nastupnymi platmi ako Java/C#. Nedavno do Prahy prisla firma, ktora sa venuje funkcionalnemu programovaniu atd...
OOP je pekne na riesenie urcitych druhov problemu. Byt proti OOP, kvoli tomu, ze ma ine oblubene 2 jazyky mi pride ako ked niekto tvrdi: "C is the best language ever".
Osobne som rad, ze je mnozstvo jazykov, a mnozstvo pristupov k problemu (nie je to nahodou Unix filozofia, stale mat slobodne na vyber?) lebo tak mam sancu na dany problem zvolit tu najvyhodnejsiu kombinaciu...
Byt proti OOP mi pride take hlupe ako byt proti [doplnte meno Vasho oblubeneho programovacie jazyka]...
-
@iwtu
http://www.tiobe.com/index.php/paperinfo/tpci/C__.html
http://www.tiobe.com/index.php/paperinfo/tpci/C.html
http://www.tiobe.com/index.php/paperinfo/tpci/Java.html
http://www.tiobe.com/index.php/paperinfo/tpci/C_.html
No comment.
-
@iwtu
http://www.tiobe.com/index.php/paperinfo/tpci/C__.html
http://www.tiobe.com/index.php/paperinfo/tpci/C.html
http://www.tiobe.com/index.php/paperinfo/tpci/Java.html
http://www.tiobe.com/index.php/paperinfo/tpci/C_.html
No comment.
Ked ste Vy clovek, ktory musi kracat s dobou, kde sa jazyku kazdu chvilu menia, nech sa paci. Niekto ma napriklad rad Unix API, programuje v C, obcas C++ a zaraba 4 krat viac ako priemerny programator Javy...
Ale kludne ingorujme firmy, co programuju funkcionalne, kludne ingorujme C, kludne ingorujme kazdu dnes minoritu, ktora zaraba niekolko nasobne viac a bez nej to v mnohych oblastiach nejde. Kludne ingorujem Assembler, ved kto uz dnes programuje Mainframy (poznam ludi, co to robia a citaju si po veceroch Knutta)...
Osobne som takmer nikdy nepatril k majorite. Dakujem za odsudenie. Prajem pekny zivot...
-
Ked ste Vy clovek, ktory musi kracat s dobou, kde sa jazyku kazdu chvilu menia, nech sa paci. Niekto ma napriklad rad Unix API, programuje v C, obcas C++ a zaraba 4 krat viac ako priemerny programator Javy...
Nejsem progamátor a živí mě správa BSD systémů, takže jestli vám to udělá radost, tak Unix API fakt můžu :)
Jinak tenhle flame absolutně nechápu. Tvrdil jste cosi o tom, jak je tomu na trhu ("Najradsej vidim prispevky, ktore vravia, ze C++ uz je na nic, lebo je dnes Java/C#") a já jsem jenom dodal podklady k tomu, že to, co tvrdíte, je jenom Váš dojem, nic víc.
Fakt, že C++ je na ústupu, je prostě fakt, i kdyby se vám to tisíckrát zdálo jako spiknutí lidí kráčejících s dobou.
-
Fakt, že C++ je na ústupu, je prostě fakt, i kdyby se vám to tisíckrát zdálo jako spiknutí lidí kráčejících s dobou.
Jsou v těch grafek započítány i nárusty počtu programátorů, které mají díky jednodušším jazykům typu C# blíže k programování, než třeba u C++? Aby se neukázalo, že těch C++ programátorů je plusmínus pořád stejně a jen do oboru přichází noví lidé
-
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, Wikipedia and YouTube are used to calculate the ratings. Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Osobně bych nepodceňoval růst Objective C, který nepochybně souvisí se zvyšující se popularitou produktů Applu, což je trend, který bude IMHO pokračovat.
-
Z toho grafu je ale jen videt, ktery jazyk roste/klesa vzhledem k ostatnim.
Relativni rust nebo pokles uplatneni vzhledem k jazyku samotnemu by byl v tomhle pripade zajimavejsi ne?
-
"Pokud není člověk prase a ke každé datové položce hned nepíše getter a setter"
A ja myslel ze principem OOP je pouzivat prave vzdycky gettery a settery, prave proto, ze muze prijit situace kdy se neco vlozi do setteru a tim se obejde prepisovani kodu na mnoha mistech treba. ALe ja sam moc get a set taky nepouzivam protoze jsem proste linej :)
-
Taky jsem myslel, že v Javě je naopak člověk prase, když gettery a settery nepíše - že to sice je práce navíc, ale je to tak správné. Kdo je teda vlastně prase? Getter a setter může být:
- i tam, kde je jeho přidaná hodnota nulová (pro důslednost - aby nebylo něco s getterem/setterem a něco jiného zase používané přímo), a v kódu bude spousta "zbytečných" getterů a setterů
- jenom tam, kde se to hodí, ale pak to zase bude "každý pes jiná ves"
-
Taky jsem myslel, že v Javě je naopak člověk prase, když gettery a settery nepíše - že to sice je práce navíc, ale je to tak správné. Kdo je teda vlastně prase? Getter a setter může být:
Naštěstí gettry a settry lze generovat a to jak v Eclipse (Java). tak v inteligentních nástrojích pro vývoj v C++ (Visual Assist X, Eclipse CDT)
-
K těm getterům a setterům - problém je v tom, že ostatním objektům (obecně) není NIC do toho, co má jiný objekt uvnitř, natož aby mohly libovolně data jiného objektu modifikovat. Protože jakmile se zpřístupní všechna data všech objektů všem, nastane několik problémů:
1. Dochází k redundanci rozhraní. Každý programátor se rozhodne s daným objektem pracovat jinak. V kódu bude chaos, někdo bude používat "nízkoúrovňové" gettery a settery (není žádný měkkýš), druhý bude používat vysokoúrovňové rozhraní, tj. požádá objekt, aby provedl celou operaci (je to systematické a méně pracné), třetí bude obě techniky střídat podle toho, jak se zrovna vyspí a čtvrtý podle toho, jestli je lichý nebo sudý týden.
2. Roste složitost kódu v objektu, pokud chceme docílit konzistentního chování. Například pokud ten kód reprezentuje geometrický útvar a chceme omezit jeho velikost, musí se to ohlídat nejenom tam, kde provádíme komplexní operaci (resize(), scale() nebo něco podobného), ale i ve všech setterech, které ten objekt mohou zvětšit.
3. Pokud chceme z nějakého důvodu změnit vnitřní implementaci (efektivita, apod.), musíme buďto změnit kód na všech místech, kde se settery a gettery používají, případně ty gettery a settery (vygenerované původně jednoduše pomocí dekorátoru nebo třeba prostřednictvím IDE) změnit tak, aby chování objektu po zavolání příslušné metody (dříve getteru nebo setteru) zůstalo stejné, resp. aby se navrátila data ve stejné podobě jako dřív.
Ano, v případě getterů a setterů mi jako menší zlo přijde je dělat jenom v případě, kdy jsou skutečně nezbytné.
-
Ano, v případě getterů a setterů mi jako menší zlo přijde je dělat jenom v případě, kdy jsou skutečně nezbytné.
To asi jo, takže nakonec jich tolik nebude. Můj styl je dokonce takový, že konfigurace objektu jde vždycky přes konstruktor. Settry už jen slouží, ke změně vnitřního stavu. Gettry mají občas výhodu v tom, že redukují duplicitní informace, pokud objekt například poskytuje informace o dalších objektech, se kterými komunikuje.
Pokud je objekt bezestavový, settry vůbec nepotřebuje. Takový objekt má výhodu, že při přístupu nepotřebuje zamykat (v MT prostředí)
-
Miroslav Prýmek: Ke getterům a setterům jsem se už vyjádřil. Co se týče UML, nic srovnatelného (podle daných kritérií) osobně neznám.
V Prologu jsem dělal jenom jednu školní úlohu, s Haskellem jsem si hrál víc, ale nikdy jsem v něm nedělal nic většího a ani nechci. Většinu toho, co nabízí Haskell, umožňuje více či méně elegantně třeba Scala, přičemž ale méně programátora omezuje (když chci vypsat něco na obrazovku, nemusím si s sebou tahat explicitně celý monitor) a souhlasím s tím, že "čistě funkcionální přístup" je dosud jenom spíš akademický koncept. Haskell má koneckonců už několikátou implementaci IO přístupu (před monádami byly tuším další dva pokusy, moc si nepamatuju, o co přesně šlo). Ten čistě funkcionální přístup ale LZE používat v co největší míře, nicméně se to ale zase podle mě tluče s některými zásadami OOP a rozhodně s běžnou praxí. FP se ale do mainstreamu tlačí i tak a objektoví fundamentalisté se s tím asi budou muset nějak srovnat. ;)
-
"Pokud není člověk prase a ke každé datové položce hned nepíše getter a setter"
A ja myslel ze principem OOP je pouzivat prave vzdycky gettery a settery, prave proto, ze muze prijit situace kdy se neco vlozi do setteru a tim se obejde prepisovani kodu na mnoha mistech treba. ALe ja sam moc get a set taky nepouzivam protoze jsem proste linej :)
skus si pozriet ine programovacie jazyky ktore pouzivaju "threads", a potom pochopis preco instancne premenne su private.
-
gettry a settry v zásade nepoužívám u objektů nesoucí konfiguraci. Prostě něco jako struktura. Ty objekty zpravidla nemají jedinou metodu, nebo mají metody, které zjednodušují nastavování některých atributů. Tam bych opravdu gettry a settry viděl zbytečné.
Právě tyto objekty pak jsou parametry konstruktorů a jiný význam, než příprava konfigurace, nemají. Ani by se neměli sdílet mezi thready
-
IMHO u setterů a getterů je třeba rozlišovat k čemu.
- jsou interní proměnné objektu, které nesou jeho vnitřní stav. Ty by neměli mít s/g, ty by neměli být vidět vůbec.
- pak jsou externě viditelné nezávislé vlastnosti objektů (např. jméno člověka). Tam by měl naopak být getter vždy a setter velmi často (např. na barvu rámečku okna)
- pak jsou externě viditeln vlastnosti, které vypovídají o vnitřním stavu objektu. Tam mívá smysl setter, ale málokdy getter (např. indikátor, zdali je stream otevřený apod.)
Mastit s/g ke každý vlastnosti a pracovat s objektem jako se strukturou není OOP, ale paskvil.
Co se týče konfiguračních objektů, u těch je otázka, jestli ve skutečnosti nejde o strukturu (teda není to objekt - samostatná entita, čistě strukturovaný vlastnost nějakého objektu). Nicméně vzhledem k tomu, že třeba časem to chce umět konfiguraci uložit (perzistence), nějak upravovat, přenášet mezi objekty atd., tak se na to často hodí nahlížet jako na objekt.
V tomdle případě jsem na vážkách, kterej přístup je správnej, asi jak kdy (podle velikosti programu, účelu struktury a také jednoduchosti s/g či properties v danym jazyku).
-
Jsem skalní zastánce OOP a proto je mým nejoblíbenějším jazykem Erlang, protože tam jsou objekty skutečně zapouzdřené, aliasing a problémy s dědičností jsou prakticky eliminovány. Teda pokud člověku nevadí, ze objektům se říká process a metodám message. Kam se hrabe takový SmallTalk.
-
Pokud mám mluvit za sebe, řekl bych, že nejsem skalním zastáncem žádného programovacího stylu nebo techniky. Podle mě IMHO mnohem více záleží na typ úlohy/problému, který jsem se rozhodl řešit pomocí vlastního programu a na tom co umím, nebo znám. Tahle univerzálnost je jeden z důvodů proč je pro mě C++ no. 1 - mohu v něm v základu volit mezi strukturálním a určitým typem objektového programovaní. A pokud chci tak mi nabízí možnosti jak implementovat / simulovat vlastnosti jiných jazyků (programovacích technik a stylů). Je to sice už mnohdy vyšší dívčí - přiznávám, že bych si na ledacos asi netroufl , ale vím, že to v C++ jde... V mnohých jiných "čistých" jazycích by to znamenalo mnohem větší problém.
Když se na různé svaté války (flamewary) za ten jediný správný jazyk, styl, techniku, ... (doplnte si, prosím, patřičný pojem) dívám z tohoto pohledu, neubráním se pobavenému úsměvu a myšlence na to, že "každá liška chválí svůj ocas..." :D
-
OOP používám jen tam kde musím a kde to přináší efekt, například když potřebuju interface s dědičností. Proč? Myslím že nevhodné použití OOP přináší celou řadu problémů:
Neduh číslo 1: automatické generování tříd z datového modelu s předgenerovanými metodami.
Vznikne džungle tříd, které nedělají vůbec nic, stovky zdrojových souborů, které by při trošce inteligence šly nahradit jedním univerzálním rozhraním pro přístup k datům (kdo tvrdí že to nejde kvůli typové kontrole, tak nejspíše nikdy neslyšel o validačních funkcích).
No a do takto vygenerovaného bludiště programátoři ukryjí vlastní kód. Ten se mezi tisíci vygenerovaných metod hledá obtížně, a při přegenerování kvůli změně schématu se většinou ztratí nebo aspoň rozbije.
Neduh číslo 2: nadužívání objektů a tříd
Třídy jsou vhodné tam, kde je potřeba objekty dynamicky nahrazovat za jiné se stejným rozhraním. U interních datových struktur, kde to nedává smysl, bych to nepoužil. Například pro formulář o 100 položkách nemá smysl vytvářet 100 různých objektů, které nedělají nic jiného než že zapouzdřují základní typy, komplikují a zpomalují manipulaci s nimi, a žerou paměť.
Neduh číslo 3: gettery a settery na úplně všechno
Myslím že gettery a settery mají místo v rozhraní modulu, který komunikuje s vnějším světem, a i tam jen v případě, že reálně očekáváme, že položka v budoucnu např. změní typ, nebo že bude potřeba nějaká reakce. Spousta programátorů je ale cpe úplně všude. V kombinaci s předchozím to znamená, že veškerý přístup k datovým strukturám se dělá pomocí řetízku volání getterů a setterů, což je nepřehledné na zápis, zpomaluje běh, a nemá žádný dobrý důvod. Pokud navíc předpokládáme, že některé položky struktury nejsou vyplněné, musíme každý jednotlivý řádek uzavřít do vlastního try .. catch bloku, nebo k němu napsat velmi dlouhý if().
Neduh číslo 4: špagetový kód
Nadměrné používání objektů a metod způsobuje, že většina metod jen předává své parametry jiným metodám a nedělá vůbec nic. Pro nalezení výkonné části musíte projít třeba deset úrovní. V takovém kódu se nedá vyznat a špatně se ladí.
Ale pokud se objekty používají s mírou a rozumem, mohou být užitečné.
-
Většina VM kritiky IMHO spíše souvisí s tím, že dost lidí chápe OOP jinak, než co to IMHO ve skutečnosti je.
1) Jak to souvisí s OOP? Kdyby teď letělo procedurální programování, tak budou lidi houfně generovat procedury na přístup k datům....
2) Pokud to někdo takhle dělá, tak to není OOP - copak je položka formuláře samostatná entita?
3) Fór je v tom, že málokdy člověk předem ví, co bude. Navíc to, co popisuješ je v přímém rozporu s myšlenkou OOP, protože se nemá přistupovat k hromadě vlastností objektu, ale zavolat jeho jedna metoda, která provede co je třeba.
4) Když je program navrženej blbě, tak je to proto, že ho navrhoval blb :-) Není to teda vina použité metody, ale toho, kdo ji používá. Naopak dobrý OOP návrh je imho nejčitelnější, protože každá entita v programu má definovanou svoji zodpovědnost a úlohu, takže nikde nedochází k sideefektům, k dělání pěti věcí najednou a podobným zhůvěřilostem, které čitelnost snižují nejvíce.
-
Neduh číslo 1: automatické generování tříd z datového modelu s předgenerovanými metodami.
Vznikne džungle tříd, které nedělají vůbec nic, stovky zdrojových souborů, které by při trošce inteligence šly nahradit jedním univerzálním rozhraním pro přístup k datům (kdo tvrdí že to nejde kvůli typové kontrole, tak nejspíše nikdy neslyšel o validačních funkcích).
Většinou je v pozadí ještě něco jiného a to znovupoužitelnost. Některé třídy vznikají jen proto, že jedna velká třída by implementovala zbytečně moc operací, pak se problém rozdělí do mnoha malých tříd, které mohou fungovat samostatně. Dám příklad. Lze udělat správce přístupu tak, že budu mít skupiny uživatelů a ke každé skupině přístupová práva. Mohu na to napsat jednu třídu. Ale taky to mohu napsat jako třídu přístupových práv, třídu skupiny uživatelů a třídu, která to spojuje dohromady. A stejně tak třídu přístupových práv lze dále dekomponovat na kolekci instancí třídy definující prostředek a jednotlivá práva. Těch tříd je tam pravda hodně, a některé budou hodně krátké, některé díky STL budou omezeny jen na nějaký typedef. Ale už budou hotové, připravené a jak platí jedno programátorské pravidlo, každá věc má být napsána v programu jen jednou.
Rozdělení na třídy neurčuje to, jak veliká ta třída má být, ale její logické začlenění do celého objektového návrhu. Řešit výkon v tomto případě nemá smysl, protože třeba překladače C++ (myslím teď třeba MS Visual C++) umí celkem dost obstojně optimalizovat, takže ve výsledném kódu třeba vůbec nějaké objekty nejsou vůbec patrné.
Hlavním smyslem OOP jazyka je čitelný zápis často abstraktních myšlenek, ne honba za výkonem. To má co nejvíc pořešit překladač (ano, uznávám, výjimečně se musí algoritmy přizpůsobovat specifikám dané platformy).
Neduh číslo 2: nadužívání objektů a tříd
.... Například pro formulář o 100 položkách nemá smysl vytvářet 100 různých objektů, které nedělají nic jiného než že zapouzdřují základní typy, komplikují a zpomalují manipulaci s nimi, a žerou paměť.
Pokud ovládací prvky nemají nějaké speciality, pak je to nesmysl. Třída vzniká tam, kde existuje odlišnost od existujících tříd. A to ještě s možností podědit existující třídu a dopsat jen tu odlišnost
Neduh číslo 3: gettery a settery na úplně všechno
Gettery a settery se tu řešili. Mnohem radši používám konfigurační třídy (struktury), které gettery a settery nemají. Konfigurační objekt pak nastavuje parametry nového objektu přes konstruktor a tím jsou vlastnosti zadané. Nadužívání getterů a setterů se mi samozřejmě taky nelíbí, ale jejich nepoužívání je také špatně. Je prostě se potřeba nad tím zamyslet, jaký vlastně ty gettery a settery mají mít smysl. Příliš velké množství getterů a setterů zpravidla ukazují na nešťastný návrh
Neduh číslo 4: špagetový kód
Nadměrné používání objektů a metod způsobuje, že většina metod jen předává své parametry jiným metodám a nedělá vůbec nic. Pro nalezení výkonné části musíte projít třeba deset úrovní. V takovém kódu se nedá vyznat a špatně se ladí.
Otázka je, chcete vůbec vidět výkonné části? OOP je práce s černými krabičkami. Pokud černé krabičce nevěříte, chápu, že se chcete dovnitř podívat... abyste zjistil, že je v ní další černá krabička (nebo krabičky). Bavme se ale o situaci, kdy máme černé krabičky, kterým věříme, pak bych tuto námitku považoval za irelevantní. Při práci v týmu, kdy každý programátor má na starost nějakou černou krabičku je výhodou i zodpovědnostní model, každá práce je oddělená a programátoři si nelezou do zelí. A pokud lezou... opět to je ukazatel nešťastného návrhu.
U OOP neřešte výkon. U některých jazyků to ani nechceme (Python, smalltalk), u některých to řeší dobrý překladač (C++, Java JITC)
-
Neduh číslo 4: špagetový kód
Nadměrné používání objektů a metod způsobuje, že většina metod jen předává své parametry jiným metodám a nedělá vůbec nic. Pro nalezení výkonné části musíte projít třeba deset úrovní. V takovém kódu se nedá vyznat a špatně se ladí.
Nelze než nevzpomenout na tu tolik milovanou Javu....
-
Neduh číslo 4: špagetový kód
Nadměrné používání objektů a metod způsobuje, že většina metod jen předává své parametry jiným metodám a nedělá vůbec nic. Pro nalezení výkonné části musíte projít třeba deset úrovní. V takovém kódu se nedá vyznat a špatně se ladí.
Nelze než nevzpomenout na tu tolik milovanou Javu....
Ano, to skutečně nelze nevzpomenout. Java sice za tento problém OOP návrhu nemůže, ale naopak ho ve svých IDE pomáhá řešit - např. http://blogs.jetbrains.com/idea/2009/08/analyzing-dataflow-with-intellij-idea/
-
Nejvíc mě ovšem dojímá kritika C++, že není objektový jazyk a jako příklad se uvádí Java, která je koncipována naprosto shodně jako C++. Smaltalkisté se vůbec rádi pouští do C++ a ty ostatní jazyky jako by přehlíželi. co si o tom myslíte? (ať flame začne v samostatném vlákně)
Je nutne si uvedomit na jakou platformu je dotaz smerovan. Jestli se bavis o programovani 16 bitovych mikroprocesoru, tak tam kvuli nedostatku pameti samozrejme jedine proceduralni jazyk C. Ale to asi neresis.
Bavis-li se o PC, tak tam uz aspon 15 let proceduralni jazyk nepatri (vyjma SQL). Duvod je jediny: Proceduralnim jazykem proste NELZE!!! programovat nektere situace a zaroven s nim NELZE programovat efektivne. Proceduralnim jazykem taky NELZE rozlisit data od logiky, coz je zakladem pro vicevrstve aplikace. Branit se OOP je jako chtit v roce 2010 jezdit z Bratislavy do Prahy na kravskem povoze. Dovede vas to tam, ale unavite se, bude vas bolet zadek, zmoknete u toho a hlavne vam to bude trvat milionkrat dele nez autem.
Ad C++ vs. Java)
C++ je opravdu desnej jazyk! Clovek v nem vice hleda zpusob jak problem vyresit, nez aby programoval funkcnost samotnou. Taky neni pravda, ze Java koncepcne vychazi z C++! Tobychom mohli prohlasit o SQL, ze vychazi z assembleru, protoze v nem lze zapsat pismenka a zavorky.
C# je momentalne nejmodernejsi a nejefektivnjsi jazyk na programovani. Jeho jedinou slabinou je multiplatformnost. Coz muze byt zasadni slabina.
V multiplatformnosti vede Java. Java ma jeste tu vyhodu, ze Javiste patri mezi nejlepe placene programatory. Duvod je ten, ze jde o rozsireny jazyk ale technicky zastaraly, takze kdyz chce nekdo vice zabavy, jde do C#, kdyz chce nekdo vice penez a nevadi mu reseni naprosto zbytecnych problemu v/s naprosto hnusnym grafickym prostredim, spatnym memory managementem, nevzhlednym zapisem kodu, s problemy Javovske prostredi rozchodit, tak jde do Javy. Nejvice pracovnich nabidek je na Javu a trva to jiz 10 let.
Mnohem efektivnejsi jazyk nez C/C++ a Java byl Delphi (potomek Pascalu), jenomze ten se bohuzel tolik nerozsiril, protoze programatori jsou divni lide, kteri si mysli, ze kdyz budou psat write-only kod (cti "zmateny, prekomplikovany, tj. necitelny") tak si o nich lide budou rikat, ze jsou vice coool. A tak kdo chtel byt cool, trapil se s C++. Delphi uz je dnes ale minulost a vetsina Delphistu presla na C#. C# vychazi z Delphi a z Javy. Vzdyt hlavni architekti C# jsou prave od Javy a od Borlandu (Delphi). Z obou svetu vzali to nejlepsi a spojili to do bezkonkurencne nejefektivnejsiho jazyka vsech dob (zatim) - C#.
Povsimnete si jednu vec! Cim vic modernejsi jazyk, tim objektovejsi. Proc asi?! Protoze objekty jsou efektivita!!! Efektivita ekonomicka, casova, efektivita pri ladeni, pri cteni a zapisu kodu. Efektivita a elegance pri reseni problemu. Efektivita pri kresleni UML diagramu. Zkuste si proceduralni apliakci zapsat do UML. Delphi byl objektovy jak by smet a aplikace se v nem psali nejrychleji, ale s prichodem C# je OOP proti Delphi jeste o nekolik levlu vykonnejsi.
Takze dnes lze uvazovat pouze o dvou jazycich - Java a C#. Jak uz jsem zminil, penize = Java, zabava = C#.
Pak jsou ruzne jine jazyky jako Python, J#, .... ale to jsou minoritni jazyky a hledat s v tom praci je problem. Sktipty taky resit nechci, to je prokleti IT. Bohuzel skripty jako HTML 5, JavaScript, PHP zas*raji tuhle IT planetu jejich neefektivitou, nachylnosti na chybovost a neladitelnosti. Skripty resit nebudem.
Pak jsou jazyky na specialni ukoly pro matematiky, fyziky, ... to je okrajova zalezitost.
No a pak jsou zastarale jazyky, jako Pascal, Foxpro, ABAP a pod. V tom se uz opravdu pouze udrzuji archaicke vykopavky, ale kdo ma to stesti, ze musi udrzovat takove aplikace, vydela si slusny balik. Ale je to opravdu o stesti.
GN!
-
[Ivan]
No, jste ukázkový příklad toho co jsem už tu jednou psal - totiž používání děla na komára. Nechápu kde jste přišel na to, že na moderních platformách nemá procedurální programování co dělat. Přijde mi to stejně geniální prohlášení asi jako tvrzení, že dneska jsou klasické vývojové diagramy o ničem, a mají se používat jen strukturogrami. tak jako některé principy a myšlenky mnohem lépe, přehledněji a jednodušeji vyjadřuje vývojový diagram, stejně tak nechápu proč nepoužívat procedurální programování, když to mnohem zjednodušší a zpřehlední konkrétní úlohu. Přikladem budiž aplikace typu filtr, na něž stačí několik dobře napsaných funkcí. Navíc stejně se procedůrám nevyhnete, protože ve všech třech jayzcích, které jste zmínil (C++, Java, C#) je rozhraní objektů implementováno z velké části procedurálně.
Hlavní ( a z mého pohledu jedinou) výhodu kterou Java oproti C++ má, je její přenositelnost, což by mělo teoreticky znamenat, že jednou aplikaci napíšu a zkompiluji a potom ta stejná aplikace by měla běžet na všech podporovaných platformách. Jejími zásadními problémy je pomalost (virtual machine + gb) a onen "špagety kód", ke kterému tak rádi programátoři v Javě inkliminují (což je dalším argumentem proti kecům typu: "Vytvořily jsme super jazyk xxx, který budete používat, protože jsme v něm odstranily nebo schovaly všechny špatnosti jazyka yyy ". Pravda, s novím jazykem však přišli nové, nebo staronové nešvary). To je takz důvod proč se snažím Javovským aplikacím na desktopu vyhýbat (ono to bohužel v mém případě stoprocentně nejde, ale snad česem lidé trochu zmoudří...)
Kdysi jsem podobnému blábolu propadl taky - někdo někde plácl, že klasická makra nemají v C++ co dělat. Všichni jsme to jak idioti bez přemýšlení papouškovaly po něm. Dneska jsem o něco moudřejší....
-
Nechápu kde jste přišel na to, že na moderních platformách nemá procedurální programování co dělat. ... nechápu proč nepoužívat procedurální programování, když to mnohem zjednodušší a zpřehlední konkrétní úlohu. Přikladem budiž aplikace typu filtr, na něž stačí několik dobře napsaných funkcí.
Tak predpokladam, ze vyznam puvodniho dotazu je dotaz na zpusob programovani ucelenych aplikaci a ne jen jedne konkretni minimalisticke ulohy, ktera sama o sobe nema vubec zadny smysl. Filtr sam o sobe nema smysl bez vyuziti v aplikaci. A psat dnes aplikaci, ktera ma aspon jeden formular a jedno tlacitko proceduralne je nesmysl, nebot musite reagovat minimalne na nekolik zakladnich udalosti a to snad nikdo uz nechce psat proceduralni metodou. Nikdo se nehada, ze v OOP programu, ktery je tvoren z trid neni misto pro procedury. Procedury jsou zakladem objektu, takze za "proceduralni" se chape stavba progrmu jako celku a ne jedne metody.
Hlavní ( a z mého pohledu jedinou) výhodu kterou Java oproti C++ má, je její přenositelnost, což by mělo teoreticky znamenat, že jednou aplikaci napíšu a zkompiluji a potom ta stejná aplikace by měla běžet na všech podporovaných platformách.
Tech vyhod meci C++ na jedne strane a Javou a C# na strane druhe je mnohem mnohem vic, ale je to imho OFF TOPIC. Nejzasadnejsi vyhoda je ovsem produktivita. Clovek v C# napise proste aplikaci rychlejsi, znacne rychleji, nez v C++. Navic nemusi resit spoustu problemu s vynimkami, s pameti, ...., kterym se v C++ nevyhne.
Jejími zásadními problémy je pomalost (virtual machine + gb) a onen "špagety kód", ke kterému tak rádi programátoři v Javě inkliminují (což je dalším argumentem proti kecům typu: "Vytvořily jsme super jazyk xxx, který budete používat, protože jsme v něm odstranily nebo schovaly všechny špatnosti jazyka yyy ". Pravda, s novím jazykem však přišli nové, nebo staronové nešvary). To je takz důvod proč se snažím Javovským aplikacím na desktopu vyhýbat (ono to bohužel v mém případě stoprocentně nejde, ale snad česem lidé trochu zmoudří...)
Javovskym aplikacim na desktopu se taky snazim vyhybat a duvod je zastaralost toho prostredi, nestabilita, problem s kompatibilitou atd... Ale resime tu spise jazyk jako takovy.
Spagetovy kod rozhodne neni takovy problem jaky s nej delate a rozhodne neni jen vysadou OOP, ale neodmyslitelne patri i k C++. Problem muzete resit 30 metodami nebo 2 metodami jak v OOP tak v proceduralnim prostredi!
Pomalost aplikaci jiz dnes nikdo neresi. Kdyby nekdo resil pomalost aplikaci, tak by nikdy nevznikaly webove aplikace, ale zustali bychom u desktopovych. Jenomze stejne tak, jak je vetsina programatoru spatnych, tak je i vetsina administratoru spatnych. Jedinym argumentem pro webove aplikace kdysi davno bylo, ze je neni potreba instalovat a tato jedina vyhoda prevalcovala vsechny ostatni vyhody desktopovych aplikaci. A kdyz lidi muzou cekat na nacitani stranky a pak ovladat UI pomoci mysi, tak nikdo z nich neresi vykon. A tech nekolik malo z nas, kteri preferuji efektivitu si vzdy nejak poradi.
Navic nikde neni receno, ze C#/Java je pomalejsi nez C++. U nekterych veci je pomalejsi, u nekterych vtykonnejsi. Celkove je ale vykonnejsi! A i kdyby nebyl, tak vykon HW roste, proto to neni potreba resit. Tim zase nechci rict, ze je spravne udelat neefektivni palikaci! To vubec ne! Jen rikam, ze neni potreba resit kraviny jakymi je porovnavani vykonu C++ a C# pri stejnem algoritmu! 99% vykonu aplikaci je o efektivite algoritmu a ne o vykonu jazyka. (Neresim skripty, to je ine kafe)
Kdysi jsem podobnému blábolu propadl taky - někdo někde plácl, že klasická makra nemají v C++ co dělat. Všichni jsme to jak idioti bez přemýšlení papouškovaly po něm. Dneska jsem o něco moudřejší....
Blabol to pro Vas bude pouze do te doby, nez nenajdete odvahu zkusit na dva tydny neco jineho. Muzu Vam garantovat, ze kdyz zacnete psat nejakou aplikaci v C# a stravite u toho dva tydny, jiz nikdy se nebudete chtit vracet k C++. Bude to pusobit na Vas stejne, jako kdyby Vam nekdo daroval zdarma mercedes i kdyz doma mate trabanta, vozil byste se na mercedesu a po dvou tydnech byste si mel vybrat, zda se vratite do trabose a mercedes nechate ve sve garazi hnit.
-
Ivan: Kvalitu tvoje příspěvku imho charakterizuje už to, že pokládáš SQL za procedurální jazyk...
Řešit problémy s výjimkami musíš v C++ úplně stejně jako v javě (jen java to o něco víc hlídá), s dobrou knihovnou nemusíš řešit správu paměti ani v C++ a naopak implementace správy jiných zdrojů (soubory, databáze etc.) se zas lépe řeší v C++ (viz problém chybějících destruktorů).
Osobně má z Tebe dojem, že umíš C# a neumíš C++ a proto je pro Tebe C# lepší. Jsou lidi, co uměj C++ daleko lépe a vsadím se, že některý úlohy by měli v C++ třikrát rychlejc, než ty v C#. Totéž platí pro Javu.
Jinak používanej jazyk rozhodně nemá majoritní vliv na produktivitu. To, co má největší vliv jsou knihovny. Viz příklad Delphi - ta dojela hlavně na svoje knihovny, které byly sice na první pohled jednoduché, ale chybové a velmi špatně rozšiřitelné - co jsem se s nina natrápil :-). Takže psát složitější projekt v Delphi bylo za trest a proto taky delphi skončilo tak, jak skončilo.
Člověk, co umí programovat, tak programuje čistě, čitelně a rychle nezávisle na jazyku. Jen si v některém musí dopsat knihovny, což ho zdržuje. Např. pro C++ už ale většinou všechny potřebné knihovny jsou, jen holt nejsou standard (což může bejt i výhoda, protože je můžeš upravit, když potřebuješ).
Jinak, co se týče objektovýho a procedurálního programování, tak tvrdit, že to či ono je lepší než to druhý je imho BLBINA, protože každý koncept řeší úplně něco jiného. Větší celek nenapíšeš rozumně a čitelně bez rozčlenění na objekty, ale samotné objekty nenapíšeš rozumně bez procedurálního programování.
-
Nikto tu ako argument nezmienil hlavnú výhodu oo návrhu a to je udržovateľnosť kódu. Pri procedurálnom návrhu sa buduje architektúra systému na báze funkcií. Objektovo orientovaný návrh používa za základ modularizácie dáta (abstraktné dátové typy). Hlavným problém funkcionálnej dekompozície je zanedbanie kritéria modulárnej spojitosti. Prax ukazuje že funkcie sú menej stabilnou časťou systému a preto by nemali tvoriť základ architektúry.
-
Vrátím se zpátky k původní otázce a začnu trochu zdálky.
Když jsem se v roce 1986 začal učite ve škole Basic, nadával mi kantor, co to dělám za prasárny, proč mám v každém programu tolik podprogramů, a co to má znamenat.
Pak jsem se začal učit soukromě Pascal, a pochopil jsem, že jsem si vlastně sám vytvořil základy procedurálního programování. Prostě to odpovídalo mému vnímání světa.
Výhody OOP jsem dodnes pořádně nepochopil, patrně proto, že by mě tento přístup nutil změnit pohled na svět. Vím, jsem v tom rarita.
Jenže pak jsem začal přemýšlet o tom, co opravdu OOP dává a co je jen markteingový kec. A došel jsem k tomu, že nevidím rozdíl mezi tím, jestli si napíšu třídu nebo knihovnu. Zapouzdření je dobrá věc, ale dá se k němu dospět programátorskou kázní (prostě do těch vnitřních dat nepolezu). Dědičnost se řeší hůř (ono takové foo.str1.str2.str3.bar pro trojnásobnou dědičnost dat vypadá hůř než foo.bar), ale s odřenýma ušima to jde taky. A polymorfismus? Tak tady přiznávám, že ten se mi rozumně nahradit nepodařilo, a tak se bez něj obcházím.
Možná se připravuju o hodně, ale vzhledem k tomu, co v současné době dělám (programuju si už jen pro zábavu, a to většinou stránky v PHP), mi to vlastně ani moc nevadí...
Omlouvám se, že k otázce nepřistupuju technicky jako vy ostatní, ale spíš filosoficky -- snad mi to odpustíte...
-
@justas
Filozoficky pohled je ten jediny spravny. Citim to podobne ale protoze jsem zazil jiz povícero podobnych 'zmen paradigma', tak jsem si jisty, ze OOP neprineslo nic. Pamatuji si totiz presne jeste tu dobu, kdy se tvrdilo, ze ted se bude programovat pomoci OOP a uz nebudou chyby v programech a vyvoj bude levnejsi ... bla bla. Nic takoveho se nestalo.
@blizzboz
OOP navrh jak pisete ma jeden problem. Je to jen jedna velka lez, ze objektovy pohled na svet je neco , co je cloveku prirozene. Opak je pravdou, cela existence lidi je zalozena na opakovani zazitych procedur.
-
@Logik pekny prispevok :-)
-
@blizzboz
OOP navrh jak pisete ma jeden problem. Je to jen jedna velka lez, ze objektovy pohled na svet je neco , co je cloveku prirozene. Opak je pravdou, cela existence lidi je zalozena na opakovani zazitych procedur.
Tak tohle bych podtrhnul a podepsal. Muj osobni nazor je naprosto stejny.
-
[Ivan]
Váš předpoklad při vší úctě nestačí, je lepší to napsat - protože z vašeho příspěvku vyplývá, že procedurální programování je pasé úplně. Jinak asi jste špatně informován, na filtrech je založena velká část unixových a like-unixových systémů. Asi jste nepsal nikdy třeba v GTK, Win32API, nebo SDL, kde se právě docela často mnohem složitější aplikace, s mnohem více ovladacích a aktivních prvků (než formulář s jedním tlačítkem) tvořilo (a dodnes i často tvoří) procedurálně v C.
Ano porovnávat C++ s Javou (a C#) je OFF TOPIC, ale když si přečtete Váš příspěvek, tak je takových OFF TOPIC srovnání PLNÝ.
Java je ve srovnání C/C++ pomalá. IMHO protože automatizovaná správa zdrojů něco stojí (a má další své mouchy - nedá se optimalizovat a občas bývá i nespolehlivá, už se to tu několikrát řešilo), navíc kód který musí být při spuštění dodatečně zpracováván, je IMHO vždycky pomalejší než strojový kód, no a nakonec jsou tu už samotné javovské aplikace, které jsou oproti jiným aplikacím stejného typu a zaměření opravdu pomalejší a navíc jejich odezva na nějakou událost bývá také často viditelně malátnější.
Imho způsob uvolnění z paměti si musíte občas implementovat i v Javě, gc pouze hlídá referece na daný objekt a jakmile žádné nejsou, pak objekt uvolní (jinými slovy, nemusíte např. volat operátor delete - jako v C++). Jednak já osobně to za žádnou výhodu (tak abych to musel používat vždy a v každé aplikaci) nepovažuji a jednak pokud bych o to stál, mám k dispozici v C++ např. inteligentní ukazatele, továrny a pod. No probléma.
Chcete mi tvrdit, že v Javě nemusíte ošetřovat vyjímky? No toto.... Nikde jsem netvrdil, že špagetový kód je přímou vinou Javy. ne jen k tomu spůsob programování v Javě dost svádí - o moc víc než v C/C++, avšak ano je to hlavně chyba programátorů. Jenže, tím se právě spousta zastánců Javy a C# ohání -> prý jedním z cílů jejich existence je psát efektivní kód bez nešvarů jejich předchůdců. A se špagetovým kódem se zápasilo (v trochu jiné formě) už na BASICU ;-) Navíc tento problém javě na výkonosti asi moc nepřidá.
Nakonec, je rozdíl, když kód pracuje na silném stroji jako modul serveru a je rozdíl když pracuje na obyčejném PC jako samostatná aplikace s plným GUI.
Já jsem zkusil jazyků myslím, že docela dost. Některé více a některé méně do hloubky, a nakonec jsem zůstal u C++. Asi jednak proto, že pro většinu problému, které řeším, mi poskytuje dostatčné nástroje a možnosti ( a pokud mi něco chybí, tak už to někdo implementoval, nebo mi to implementovat umožní - s mnohem menším úsilím, než v jazycích vyšší úrovně), nic za mě nedělá a nic přede mnou neschovává, a nakonec mi umožnuje samostatně rozhodovat co, kdy a jak se bude dělat. Mohu použít téměř jakýkoliv styl programování. (Je libo typy/objekty, funkce, metaobjekty, nebo něco speciálnějšího... např lispovské seznamy typů?) Je tedy velice flexibilní a výkonný. Ano, má to i své mouchy - a co nemá? Mě však předešlé vlastnosti C++ za to stojí. Toliko k mercedesu v garáži.
-
@blizzboz
OOP navrh jak pisete ma jeden problem. Je to jen jedna velka lez, ze objektovy pohled na svet je neco , co je cloveku prirozene. Opak je pravdou, cela existence lidi je zalozena na opakovani zazitych procedur.
Tak tohle bych podtrhnul a podepsal. Muj osobni nazor je naprosto stejny.
dnes sa uz psychiatrii zhodoju, ze clovek nema prirodzenost :-) Vidno to na uplne rozdielnych etnickych zvyklostiach atd.... OOP moze prist prirodzeny managerovi alebo cloveku na nom zvyknuty. I ked stale si myslim, ze to zalezi od problemu k problemu. Niekomu sa vidi prirodzeny iba Assembler alebo Haskell. Na co sa clovek nastavi, to mu pride prirodzene... Moj skromny nazor :-)
-
[jk & blizzboz]
Myslím, že pravdu máte oba. Objety v "realitě" existují - konec konců i člověk sám je objekt... objekt, který vykonává zažité procedůry...
-
Pri procedurálnom návrhu sa buduje architektúra systému na báze funkcií. Objektovo orientovaný návrh používa za základ modularizácie dáta (abstraktné dátové typy).
Jak jste na tohle prisel? Jeden z mych nejoblibenejsich citatu o programovani je od Linuse*:
"I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Kazdy rozumny architekt zacina od datovych struktur, ktere bude potrebovat! Jestli je OOP lepsi - ne vsechny vztahy mezi daty lze zabalit do objektu, takze muj postoj je ambivalentni.
*A asi neni treba rikat, jaky ma Linus nazor na C++. Nazor na Javu co vim nikde nerikal, ale patrne by odpovedel jen gestem.
-
K tematu jsem se vyjadril a kdyz vidim tu rekl bych az fanaticku zkostnatelost a strach zkouset nove veci u svych kolegu programatoru, tak me az mraz po zadech prechazi.
Kdo nechce videt vyhody OOP (a to je uz rok 2010) a modernich jazyku, kdo tvrdi, ze nas svet neni z objektu, ale z procedur, kdo nevidi zavislost efektivity programovani a vyvoje na jazyku, ..., ..., ... tomu IMHO neni pomoci.
Nastesti si kazdy muze vybrat jak si bude vydelavat na zivobiti a jak obstoji v konkurenci.
Bye Bye
Your mind is like a parachute. It only works if it is open. Frank Zappa
-
objektovo sa da programovat aj v C alebo ASM. C++,Java,C# tomu len pridavaju syntakticky cukor.
-
Kdo nechce videt vyhody OOP (a to je uz rok 2010) a modernich jazyku, kdo tvrdi, ze nas svet neni z objektu, ale z procedur, kdo nevidi zavislost efektivity programovani a vyvoje na jazyku, ..., ..., ... tomu IMHO neni pomoci.
Pokud mate otevrenou mysl, zkuste se nekdy podivat na objektovy model Common Lispu (CLOS), jakoz i jazyk samotny. Pak mozna "modernitu" modernich jazyku uvidite v jinem svetle.
-
objektovo sa da programovat aj v C alebo ASM. C++,Java,C# tomu len pridavaju syntakticky cukor.
Jasne, vzdyt jsem psal, ze z Bratislavy do Prahy se da dojet i na kravskem povozu a auto staci nechat v garazi.
-
Ivan: Anebo se taky dá říct, že primitiv vyžaduje, aby objektovej jazyk se zapisoval s tečkou mezi objektem a metodou, zatímco inteligentnímu člověku je jedno, jak se to zapisuje.
Co se týče bohatosti syntaxe a jejích možností, je na tom CLOS daleko lépe než C#. Akorát se tam holt nepíše ta tečka, takže to prostě není a nemůže být OOP, že. A mluvit se dá taky pouze a jen anglicky a kdo to nevidí a chce mluvit jinak, tak je blbé, že?
kdo nevidi zavislost efektivity programovani a vyvoje na jazyku
Posadím Tě k C# ořezaném o všechny knihovny. Sám budu psát ve Visual Basicu s knihovnama. Schválně, kdo bude produktivnější....
Anebo jinak - to si fakt myslíš, žes jedinej pupek světa, kterej přišel na to, že C# je jedinej produktivní jazyk, zatímco miliony programátorů po celém světě jsou blbci, který neuměj programovat a zbytečně ztrácej čas? Chlape, tvoje sebevědomí bych fakt nechtěl mít...
PS: Jako úsměvná epizoda na dokreslení pak působí x letá snaha MS napsat Windows znovu v managed kódu v C#. Pět let někde a zbyl z toho nejméně úspěšný (snad kromě windows ME a obstarožních Windows 1.0) operační systém, co kdy MS vydal - Visty. Napsanej hezky postaru povětšinou v C/C++.
----
Jinak opakuju, svět sice je z objektů, ale ty spolu interagujou pomocí procedur. Takže oddělovat OOP a procedurální styl nelze. I starý dobrý unity v turbopascalu nebo unixový sockety jsou objekty, jen se jim prostě v tý době tak neříkalo.
-
Jinak opakuju, svět sice je z objektů, ale ty spolu interagujou pomocí procedur. Takže oddělovat OOP a procedurální styl nelze. I starý dobrý unity v turbopascalu nebo unixový sockety jsou objekty, jen se jim prostě v tý době tak neříkalo.
Naprostý souhlas.
Ono to nakonec dopadá tak, že analytik navrhne vhodné datové struktury a programátor zpracuje funkce pro jejich komunikaci. A ten analytik a programátor může být klidně jedna a táž osoba. Potom vlastně dojde ke spojení dat a funkcí pro jejich správu - a máme tu objekt :-)
-
Anebo jinak - to si fakt myslíš, žes jedinej pupek světa, kterej přišel na to, že C# je jedinej produktivní jazyk, zatímco miliony programátorů po celém světě jsou blbci, který neuměj programovat a zbytečně ztrácej čas? Chlape, tvoje sebevědomí bych fakt nechtěl mít...
Nejdriv se nauc cist! Ja jsem nikde kategoricky netvrdil, ze C# je jediny pupek sveta! Takze se k Tvemu urazlivemu a neproduktivnimu prispevku nebudu vyjadrovat.
Jinak opakuju, svět sice je z objektů, ale ty spolu interagujou pomocí procedur. Takže oddělovat OOP a procedurální styl nelze. I starý dobrý unity v turbopascalu nebo unixový sockety jsou objekty, jen se jim prostě v tý době tak neříkalo.
Ne! Interakce mezi objekty v realnem svete neprobiha pomoci procedur, ale pomoci udalosti a parametry, ktere objekt prijima a vydava jsou taky objekty. Takze pokud nepochopis o cem OOP, tak logicky nemuzes videt jeho vyhody.
-
Ne! Interakce mezi objekty v realnem svete neprobiha pomoci procedur, ale pomoci udalosti a parametry, ktere objekt prijima a vydava jsou taky objekty. Takze pokud nepochopis o cem OOP, tak logicky nemuzes videt jeho vyhody.
Jake vyhody? Ostatni poucujete, jak maji uzavrenou mysl, a sam nic nevite o generic functions a multiple dispatch.
-
Jinak opakuju, svět sice je z objektů, ale ty spolu interagujou pomocí procedur. Takže oddělovat OOP a procedurální styl nelze. I starý dobrý unity v turbopascalu nebo unixový sockety jsou objekty, jen se jim prostě v tý době tak neříkalo.
Naprostý souhlas.
Ono to nakonec dopadá tak, že analytik navrhne vhodné datové struktury a programátor zpracuje funkce pro jejich komunikaci. A ten analytik a programátor může být klidně jedna a táž osoba. Potom vlastně dojde ke spojení dat a funkcí pro jejich správu - a máme tu objekt :-)
Jen Vám to pak někdo nesmí změnit :-)
-
Nejdriv se nauc cist! Ja jsem nikde kategoricky netvrdil, ze C# je jediny pupek sveta!
Opravdu jsi to netvrdil?
C# je momentalne nejmodernejsi a nejefektivnjsi jazyk na programovani.
No comment.
-----
Ne! Interakce mezi objekty v realnem svete neprobiha pomoci procedur, ale pomoci udalosti a parametry, ktere objekt prijima a vydava jsou taky objekty..... Takze pokud nepochopis o cem OOP, tak logicky nemuzes videt jeho vyhody.
Mě je úplně jedno, jak nazveš argument funkce. Furt v drtivé většině OOP jazyků: přijmout zprávu = zavolat metodu = spustit proceduru. Alespoň teda v C#, v některejch OO jazycích (např. onen CLOS) to opravdu tak není (viz dále).
A jak např. bez procedurálního programování zparsovat hlavičky mailu by mě zajímalo. Jako myslíš najdu objekt znak, kterej je dvojtečkou, všechno předtím je objekt název položky, všechno za tím až po objekt znak konce řádky je objekt položka hlavičky... A je tam všude slovo objekt, takže je to OOP, že?
Netvrdím, že to nejde bez procedurálního programování, parsovat mail jde i v prologu či lispu. Protože pro popis algoritmu existují dva přístupy: procedurální a deklarativní - C# je procedurální, prolog/lisp deklarativní. Žádnej OO popis algoritmu ale neexstuje, OOP popisuje jak se má dělat interakce mezi objekty a jak mmá vypadat objekt, nikoli jak jsou implementovány objekty uvnitř.
(Teda neexistuje - pokusy samozřejmě jsou, např.
http://www.cse.ohio-state.edu/sce/papers/algorithms-paper/algorithms-paper.pdf
ale tam to zas končí u druhé alternativy - deklarativního programování.)
A naopak procedurální programování popisuje jak popsat algoritmus, čili jak posloupností jednodušších kroků provést jednu konkrétní věc, čili jak implementovat jednu konkrétní fci. To, jestli získání 5tého znaku z řetězce se napíše charat(string, 5) nebo string.charat(5) je z hlediska procedurálního programování šumák.... a vlastně z hlediska OOP taky.
-
Nejdriv se nauc cist! Ja jsem nikde kategoricky netvrdil, ze C# je jediny pupek sveta!
Opravdu jsi to netvrdil?
C# je momentalne nejmodernejsi a nejefektivnjsi jazyk na programovani.
No comment.
Znovu vytrhujete jednu vetu z kontextu! Psal jsem, ze na ruzne ulohy je efektivni jiny jazyk, ale ano, kdyz se budeme bavit o beznych aplikacich na PC, tak plati, ze C# je nejefektivnjesi.
-
Ja bych se s dovolenim tak trochu vratil k OP.
Nuze, zastancem OOP jsem, v jeho (dle meho nazoru) nejpraktictejsi forme, kterou dnes nachazim predevsim v C# (prinejmensim pro vetsi aplikace).
Nevyzaduji zadnou filosofickou cistotu - nenamlouvam se ze aplikace se sklada jen z "posilani zprav", protoze na urovni tech nejmensich kroku - operace s primitivy (tim nemyslim hloupe programatory :) budou vzdy proceduralni, bez ohledu na syntax. Takze taky neronim slzy nad konstatovanim ze tu a tam jsou potreba globalni promenne a globalni kod (v C# "static"), a ze vlastne "staticka trida neni trida" apod.
Na druhou stranu si nenamlouvam ale ani to ze aplikace se sklada jen z algoritmu a ze tudiz kdyz "Žádnej OO popis algoritmu neexistuje" tak z toho plyne ze neexistuje ani OO program.
Proste zlata stredni cesta.
-
Na druhou stranu si nenamlouvam ale ani to ze aplikace se sklada jen z algoritmu a ze tudiz kdyz "Žádnej OO popis algoritmu neexistuje" tak z toho plyne ze neexistuje ani OO program.
Ale to já netvrdím. Já jsem taky zastánce OOP. Akorát tvrdím, že OOP řeší jiné problémy než procedurální programování. Prostě jsou OOP procedurální jazyky (např. C# nebo Java) a OOP deklarativní jazyky (CLOS nebo ten paper co jsem postoval) takže říkat, že OOP je lepší horší než procedurální programování je prostě blbina, stejně jako nejde říct, jestli je lepší mlýnek na maso nebo pánev.
No a druhá věc, kterou tvrdím je, že většina dnešních jazyků má natolik obdobné vyjadřovací schopnosti, že daleko víc záleží na knihovnách, než na samotném jazyku. Proto jsou např. tak placení Javovští programátoři. Ne za Javu samotnou (jazyk samotnej se člověk naučí za pár hodin), ale za znalost knihoven (spring, hibernate atd...).
Následující už je spíše dojem, to nemám nijak podložené fakty:
Proto také C# připadá hodně "samostatným vývojářům" tak produktivní - jeho knihovny jsou hodně cílené na RAD. Zatímco Java (a hlavně její knihovny) je víc cílená na korporátní projekty (např. existuje C# ekvivalent hibernate?) - proto není tak obratná na RAD, ale zároveň proto je i tak dobře příjmaná na velké projekty.
-
Ale to já netvrdím. Já jsem taky zastánce OOP. Akorát tvrdím, že OOP řeší jiné problémy než procedurální programování. Prostě jsou OOP procedurální jazyky (např. C# nebo Java) a OOP deklarativní jazyky (CLOS nebo ten paper co jsem postoval) takže říkat, že OOP je lepší horší než procedurální programování je prostě blbina, stejně jako nejde říct, jestli je lepší mlýnek na maso nebo pánev.
Presne tak. Podle me hadat se, zda je lepsi OOP nebo proceduralni programovani je jako hadat se, zda jsou v jazyce dulezitejsi slovesa nebo podstatna jmena. Viz tez http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html (http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html).
-
OOP nepotrebuje, aby som ho zastaval.
Naopak, ja potrebujem OOP:
- aby som mohol pouzivat tisicky metod, ktore napisali ini ludia.
- aby som vedel zorganizovat vlastny kod.
Nehovorim, ze OOP je vseliek. OOP nezabranuje problemom. OOP je pristup, ktory nieco umoznuje. Pre mna je OOP dar z nebies.
-
JS: To jsem neznal. A je to fakt dobrý :-)
-
Ak niekto nazve Smalltalk alebo Ruby objektovými jazykmi tak nepochopil o čom OOP vlastne je. Smlltalk a Ruby sú jazyky, ktoré porušujú základné princípy OOP.
-
Ak niekto nazve Smalltalk alebo Ruby objektovými jazykmi tak nepochopil o čom OOP vlastne je. Smlltalk a Ruby sú jazyky, ktoré porušujú základné princípy OOP.
To jsou ponekud silna slova, uvazime-li, ze to byl autor Smalltalku, kdo termin OOP vymyslel. Viz tez http://www.paulgraham.com/reesoo.html (http://www.paulgraham.com/reesoo.html). Ktere z tech bodu tam zminenych jsou podle vas to prave OOP?
-
Já jsem zastáncem prasoprogramování. Nedodržuji základní programátorské konvence a skoro pořád používám příkaz goto. :-D
-
Bobr: To já programuju zásadně objektově:
program.goto(radka)
:-D
Dekel: Jazyk porušuje principy OOP? Já měl za to, že jedinej , kdo je může porušit je programátor. Jazyk k tomu akorát může či nemusí dávat vhodné vyjadřovací prostředky.
Jinak také se obávám, že OOP tady nepochopil nikdo jiný - a ve slušné diskusi je zvykem
svá tvrzení podkládat argumenty a ne vytvářet flametvorné výkřiky do tmy :-)
-
Nikde jsem v diskuzi nenašel hlavní důvod pro použití OOP jak to vidím já.
Je to rozhraní. A stím související kontejnery objektů.
Příklady :
a/ evidence něčeho na webu
definuju rozhraní které umí objekt načíst, uložit, zobrazit jeho formulář, zvalidovat jeho formulář, vypsat seznam položek a popř. vyhledat. Jeden objekt může implementovat třeba uživatele, jiný třeba auta ve firmě, atd ... K tomu pak stačí zobrazovací nadstavba která pracuje s objekty implementujícími toto rozhraní. A je jí jedno čeho se ta evidence týká. A když chci přidat objekt, stačí napsat jen tento objekt.
b/ lineage server napsaný v javě
například rozhraní pro zbraně. Když chci vytvořit novou zbraň se speciálními vlastnostmi, definuju tento objekt s rozhraním jaké má mít zbraň. A hra už ho umí použít sama. Tady se navíc použije i dědičnost - použiju nějakou jinou zbraň a přidám speciální vlastnosti (např. na dinosaury je 2x účinnější než na draky)
-
Ne že bych byl proti OOP, ale právě to co jsi teď postnul ukazuje limity OOP v Javě/C# a nadužívání dědičnosti.
Chci zbraň co dává 2x drakům. Podědím ze zbraně. Chci zbraň, co dává 2xskřetům. Ok, také podědím ze zbraně. No a teď chci zbraň, co dává jak 2xdrakům, tak 2xskřetům. A z čeho ji mám podědit?
Např. podědím-li jí opět ze zbraně, dosti špatně pak budu implementovat nestvůru, která je zranitelná právě jen zbraněmi, které dávají minimálně 2x skřetům, protože mám dvě nesouvisející třídy, které obě popisují zbraň s danou vlastností.
Jojo, OOP rulez, ale ani OOP nezaručí jednoduchou a na první pohled jasnou architekturu programu...
-
No to byly takove triviální příklady pro ty co o rozhraní neslyšeli - znají jen dědičnost.
Do L2j serveru přispívá několik desítek (možná stovek) lidí. A díky rozhraní nemusí znát vše, stačí nastudovat jen to co chtějí přidat/měnit/opravit. S tím příkladem co píšeš by je komunita hnala ... I když občas tam taky člověk najde zvěrstva.
S OOP i bez OOP se dají napsat špatné a dobré programy.
-
Tak jak bys to teda vyřešil pomocí rozhraní? :-)
(IMHO rozhraní Ti tady právě zas až tak nepomůže... ale třeba se pletu....)
-
Myslím že si nerozumíme. Objekt zbraně kterou držím v ruce implementuje rozhraní zbraně.
Rozhraní zbraně má řekněme k dispozici výchozí definici která načítá hodnoty z databáze. Můžu a nemusím ho použít. Lépe je použít ho - jednodušeji budu modifikovat třeba její hmotnost a rychlost - jen nastavením v databázi.
Teď záleží, co vlasně chci. Pokud je to speciální vlasnost zbraně, přidám modifikaci metody útočná sila podle třeba počasí, nepřítele, ... Pokud chci zavést nový typ všeobecněji - bude třeba změnit rozhraní a udělat refaktorizaci. Včetně databáze. To mi naopak umožní zavést tyto vlastnosti jednoduše do zbraní co dědí úvodní implementaci. U ostatních, co si někdo splácal na koleně to vyhodí chybu implementace rozhraní - nebudou mít metody které jsem přidal. Takže pokud chci aby měly všechny zbraně vlastnost na draky, na skřety udělám to takto.
Můžu ale udělat i tu nestvůru. Změním její metodu příjmu zranění. Bude reagovat na konkrétní objekt který na ní útočí. A pokud byla zbraň A na skřety, B je potomkem A který má navíc i draky tak budu reagovat na instanci B.
Rozhraní je o tom - že někdo kliknul na útok. A algoritmus který počítá útok neobsahuje žádné konkrétní hodnoty - vše mu řekne zbraň kterou útočím. Nikdy nebudu muset měnit algoritmus který řeší útok kvůli přidání zbraně. A dokonce pokud udělám bug - projeví se jen při použití zbraně. Odladěný algoritmus útoku se ani nehne.
Kdyby to nebylo přes OOP, musím při každé změně šahat do algoritmu co řeší útok. Dodělávat do něj podmínky, zanášet konkrétní hodnoty. Časem by z něj byl velký kus kódu. Blbě laditelný a nepřehledný.
-
Takže pokud budu dělat zbraň na skřety, tak tam musím znovu zopakovat celou metodu jak se útočí a někam dovnitř tam vepsat modifikátor x2? Nebo jak.
A když takových zbraní vyrobím třicet, tak tam budu mít třicet skoroduplicitních kódů? A když pak budu chtít změnit algoritmus útoků všech zbraní.... No fuj.... To už snad radši ten neOOP přístup. :-)
Anebo z jiné strany - mám zbraň na skřety. Mám zbraň na draky. Jak z toho jednoduše vyrobím zbraň, která kombinuje vlastnosti obou?
Ono samozřejmě že OOP přístup je lepší (spíš bych řekl že je nejbližší realitě a proto přináší nejméně problémů), ale zrovna přístup chci modifikaci objektu, tak ho podědím je imho
velmi špatný.
Copak zbraň více zraňující skřety je něco "speciálnějšího" než zbraň? Copak ona umí něco více, poskytuje něco co běžná zbraň ne? Tak proč dědičnost? Zraňovat více skřety je vlastnost zbraně a jako taková by měla být implementována: tedy nikoli dědičností, ale agregací dané vlastnosti.
B je potomkem A který má navíc i draky tak budu reagovat na instanci B.
Fuj. To je právě to. A proč je zbraň která je na skřety i draky potomkem zbraně, která je jen na skřety a ne potomkem zbraně, která je jen na draky? Nebo potomkem obou? (což jaksi v javě/C# nejde a v C++ je zdrojem velkých problémů...
Můžu ale udělat i tu nestvůru. Změním její metodu příjmu zranění.
To můžu, ale dostanu se do stejnejch problémů u nestvůry, která bude skřet i drak (skřetodrak, no fuj :-) ).
Pokud chci zavést nový typ všeobecněji - bude třeba změnit rozhraní a udělat refaktorizaci. Včetně databáze. ..... U ostatních, co si někdo splácal na koleně to vyhodí chybu implementace rozhraní - nebudou mít metody které jsem přidal.
Bavíme se o OOP? Já měl za to, že v OOP implementace potomka NESMÍ zasahovat do implementace předka. Pokud pro novej typ musím modifikovat předka, něco jsem udělal špatně...
Právě proto, aby fungovali i objekty, co napíše někdo jiný...
-
To mi přijde jako o voze a koze.
Nepsal jsem nic o modifikaci předka. Psal jsem o refaktorizaci a změně rozhraní. Je jasné, že pokud musím udělat 30 téměř stejných objektů, měl bych přehodnotit zda není třeba refaktorizace. To je stejné pro OOP jako bez objektů.
Vrátil bych se k tomu co považuji za výhodu OOP - to jsou kontejnery objektů implementujících rozhraní. To je v neOOP o dost méně přehlednější. A náročnější na chyby a odladění.
-
Změna rozhraní je totéž jako změna předka - prostě v okamžiku, kdy todle člověk musí udělat, tak byla provedena špatně analýza.
Nevím, o jaké koze se bavíš ty :-), ale já celou dobu upozorňuju, že to, co jsi napsal jako ukázkový příklad OOP: "potřebuji modifikaci vlastnosti objektu, tak z něj udělám potomka", nemá s OOP moc společného, protože to porušuje hned několik zásad OOP
- používá to dědičnost tam, kde nepatří
- nevede to k znovupoužitelnosti kódu
- nutí to modifikovat předka/rozhraní při implementaci potomka
-
Bobr: To já programuju zásadně objektově:
program.goto(radka)
:-D
Dekel: Jazyk porušuje principy OOP? Já měl za to, že jedinej , kdo je může porušit je programátor. Jazyk k tomu akorát může či nemusí dávat vhodné vyjadřovací prostředky.
Jinak také se obávám, že OOP tady nepochopil nikdo jiný - a ve slušné diskusi je zvykem
svá tvrzení podkládat argumenty a ne vytvářet flametvorné výkřiky do tmy :-)
tu máš argumenty: http://latrine.dgx.cz/ruby-on-rails-dekuji-nechci
ja som pochopil OOP na OOP zarábam peniaze. jazyk + knižnice a frameworky by mali (do určitej miery) programátora viesť k tomu aby neporušoval princípy OOP.
-
Ruby moc rád nemám. Nicméně to co ukazuješ je čistě jedna povolná možnost, která se v určitých případech hodí. Pokud ji nechceš v projektu používat, nemusíš. Můžeš dokonce snadno statickou analýzou kódu vyloučit, že se daná možnost nebude používat.
Nicméně jsou naopak případy, kdy se daná vlastnost velmi hodí. Např. pro opravu cizí knihovny, když do ní nechci zasahovat (např. proto, že případný upgrade této knihovny mi opravu zas rozbije).
Oheň není špatný, špatný je člověk, který s ním zapálí barák.
Stejnětak prototypová dědičnost. OOP se nerovná třídy a objekty. OOP jsou paradigmata, jak správně navrhnout architekturu programu. Samozřejmě, když se pomocí prototypů budeš snažit emulovat pouze třídní dědičnost, tak Ti zbydou jen nevýhody. Když se jí naučíš používat, tak zjistíš, že má daleko silnější výrazové prostředky než klasická třídní dědičnost a při zachování elementárních pravidel nebude o nic chybovější.
Že cizí knihovny mohou mít v JS sideefekty? To mohou mít i cizí knihovny v C#. Např. funkce na setřídění Ti může jednou za čas z pole něco vyhodit. Že se to nedělá a že je to prasečina? Ale to je i modifikování globálních objektů v JS. Buďto srovnávejme správně napsané knihovny, nebo špatně. Srovnávat dobře napsané knihovny v C# a špatně v JS je trochu nefér, ne?
Samozřejmě - můžeš furt jíst syrový maso a máš jistotu, že se nepopálíš. Někomu však to pečený za tu možnost stojí...
Teď mě ještě napadá:přístup JAVY: socialismus. Zakážeme vše potenciálně nebezpečné, co kdyby něco. Přístup javascriptu. Dovolíme skoro vše, je na Tobě jestli to ke své škodě zneužiješ či ne. Nevím jak ty, ale já bych si socialismus nevybral... (a to mám Javu rád).
-
Změna rozhraní je totéž jako změna předka - prostě v okamžiku, kdy todle člověk musí udělat, tak byla provedena špatně analýza.
Nemáte pravdu. Moje objekty běžně umí vícero rozhraní, nebo je umí různě proxovat. Pokud potřebuju přidat něco do rozhraní a přitom nechci to rozhraní přepisovat všude, napíšu to jako nové rozhraní a každá třída, u které to má smysl to rozhraní implementuje. A tam, kde potřebuju nové rozhraní použít nejprve ze starého rozhraní nechám získat nové. V C++ je na to operator dynamic_cast
Při vývojit tedy většinou rozhraní nemění, jen je přidávám. Takhle je navržen třeba celý DirectX. Například dnešní DirectX10 umí naprostou většinu starších rozhraní ze všech starých verzí.
-
Jsou dvě možnosti. Buďto nové rozhraní umí něco navíc. Pak nejde o změnu rozhraní, ale o vytvoření nového rozhraní, popisující nějaký speciálnější případ, rozšiřující funkčnost starého. To je v pořádku - tady nejde o změnu rozhraní, ale např. o vytvoření potomka rozhraní.
Druhá možnost je, že opravdu potřebuji změnit staré rozhraní. Tzn že jen potřebuji popsat naprosto stejnou věc, ale pomocí jiných sad metod.
Pak samozřejmě když místo změny udělám rozhraní verze2, tak si částečně ušetřím práci. Ale za cenu toho, že mám v programu o jedno rozhraní navíc (program je tedy nepřehlednější) a některé třídy budou implementovat zbytečně duplicitní metody (což je další možný zdroj chyb - člověk upraví jednu a druhou nikoli).
Dynamic_cast ze starého na nové je pak víceméně rezignace na největší výhodu staticky typovanch jazyků: typovou kontrolu. Protože nikdy nemohu zajsitit, že opravdu všechny objekty co do té fce přijdou, budou to nové rozhraní opravdu umět.
Další věc je, že objekt s novým rozhraním zpravidla pomocí starého rozhraní ani popsat nepůjde (pokud by šel, tak proč by bylo potřeba vytvářet nové rozhraní):
Např. rozhraní myslivec s metodou getPes() - no a pak potřebuju vytvořit myslivce se dvěma psy. Jasně getPes() může vrátit prvního psa. Jenže pokud bude někdo pomocí této metody testovat, čí pes to zakousl jeho králíka, tak se nic nedoví.
Samozřejmě, od projektů určité velikosti a hlavně stáří není vyhnutí a trochu "bastlit" se musí. Člověk by ale měl vědět, že zrovna bastlí a nepovyšovat to na standardní techniku.
Když to zjednoduším - proč musím měnit rozhraní? No protože nevyhovuje. A je udělané dobře, když nevyhovuje? No evidentně není, jinak by přeci vyhovovalo. Co jiného od rozhraní mohu chtít....
-
Dynamic_cast ze starého na nové je pak víceméně rezignace na největší výhodu staticky typovanch jazyků: typovou kontrolu. Protože nikdy nemohu zajsitit, že opravdu všechny objekty co do té fce přijdou, budou to nové rozhraní opravdu umět.
Další věc je, že objekt s novým rozhraním zpravidla pomocí starého rozhraní ani popsat nepůjde (pokud by šel, tak proč by bylo potřeba vytvářet nové rozhraní):
Např. rozhraní myslivec s metodou getPes() - no a pak potřebuju vytvořit myslivce se dvěma psy. Jasně getPes() může vrátit prvního psa. Jenže pokud bude někdo pomocí této metody testovat, čí pes to zakousl jeho králíka, tak se nic nedoví.
No dynamic_cast je náplastí na bolístku u OOP jazyka, jehož objekty neumí zpracovat jakoukoliv zprávu. Když si třeba vezmete Smalltalk... tam to jde normálně. Díky dynamic_castu se mohu objektu zeptat, zda podporuje nějakou sadu zpráv... jinými slovy, podporuje určitý protokol, stejně jako když v klasické smalltalkovské představě se mohu zeptat objektu, zda umí zpracovat určitou zprávu.
Pokud tohle přijmete, můžete pracovat s objekty jako s černými krabičkami, které podporují různá rozhraní a stačí jen změnit úhel pohledu (rozhraní) a získat tak nové vlastnosti, které staré rozhraní neumí. Neznamená to, že to neumí objekt.
Příklad myslivce a psa... je pěknou ukázkou nepochopení toho, jak se aplikace rozšiřuje. Nejdřív se ptám, proč musím vědět, s jakým psem myslivec pracuje? Doposud jsem to nepotřeboval. No tak tam, kde to nepotřebuju může ta metoda vrátit nějakého náhodného psa, jestli že jich má víc, nebo toho prvního, nebo psa podle datumu v kalendáři. To je fuk, doposud to smysl mělo. Tam kde potřebuju víc, přetypuju si IMyslivec na IMyslivec2, který už počítá s tím, že myslivec může mít víc psů.
dynamic_cast, narozdíl od dynamických jazyků, má výhodu v tom, že si rozhraní vyresolvím jen jednou na začátku, a pak mohu pracovat už s novým rozhraní, stejně rychle jako se starým rozhraní.
-
No tak tam, kde to nepotřebuju může ta metoda vrátit nějakého náhodného psa, jestli že jich má víc, nebo toho prvního, nebo psa podle datumu v kalendáři. To je fuk, doposud to smysl mělo.
Ale nemělo. Copak myslivec může vlastnit pouze jednoho psa? Nemůže. Takže prostě rozhraní myslivec nepopisovalo objekt myslivec správně. Akorát to autor programu nepotřeboval, tak mu to zatím nevadilo.
Samozřejmě, jde to relativně bez větších úprav programu zalepit novým rozhraním a dynamic_castem, ale:
* místo statické kontroly datových typů za překladu mám dynamickou kontrolu typů za běhu. Tzn. ztratím veškeré výhody staticky typovaného jazyka (kontrolu za překladu a hlavně bezpečnou kontrolu - u kontroly za běhu nikdy neotestuji co všechno na dané místo může doputovat), aniž bych se ale zbavil jeho nevýhod (např. nutnost uvádět typy).
* v okamžiku, kdy potřebuji myslivce se dvěma psy, tak musím přepsat velkou část objektů, které s myslivcem se psem pracují - přesněji všechny, které pracují se všema psy myslivce (jinak se program nechová správně).
Např.: Setkání s veterinářem (má naočkovat všechny psy), kontrola myslivce na hranici (kontrola, jestli má myslivec na psy papíry), setkání s rasem (chudinci pejsci), setkání s číňanem (only joking :-), my zas jíme hindům krávy :-)) atd...
No a tady je implementace nového rozhraní vyloženě nebezpečná, protože mi nikdo neřekne, které všechny objekty takto s myslivcem interagovaly, takže u většího programu skoro s jistotou na něco zapomenu. Takže sice budu mít "funkční program" ale přes hranice my myslivec s jedním nenaočkovaným psem projde.
Proto tvrdím, že je chybou původního návrhu, když v něm myslivec nemůže mít víc psů - když je teoreticky možné, že by jich měl více. I když to program v tuto chvíli nepotřebuje a i když si pak mohu nadefinovat nové rozhraní.
Samozřejmě někdy by implementace multipsího myslivce (obecně implemntace přesnějšího popisu reality) byla o tolik složitější, že se to nevyplatí a je lepší udělat "chybu" záměrně. To však neznamená, že člověk nedělá "chybu", jen o ní ví :-)
Přirovnal bych to k situaci, kdy se člověk rozhodne používat Newtonovu mechaniku (a zanedbá relativitu). To je samozřejmě korektní postup, ale
- člověk musí vědět, že něco zanedbává
- měl by si bejt OPRAVDU jistej, že tu relativitu potřebovat nebude.
Pokud napíšu systém s Newtonovou teorií a následně zjistím, že potřebuji relativitu, udělal jsem chybu. Pokud napíšu program s rozhraním myslivce se psem a pak zjistím, že potřebuji multipsa, udělal jsem chybu.
-
tam, kde to nepotřebuju může ta metoda vrátit nějakého náhodného psa, jestli že jich má víc, nebo toho prvního, nebo psa podle datumu v kalendáři. To je fuk, doposud to smysl mělo. Tam kde potřebuju víc, přetypuju si IMyslivec na IMyslivec2, který už počítá s tím, že myslivec může mít víc psů.
Za tohle by se melo kamenovat :)
Kdyz jsem myslivec s vice psy, je absurdni abych se vydaval za myslivce s jednim psem (tj. abych implementoval puvodni rozhrani), protoze to NIKDY nebude spravne. Tohle je presne cesta kterou se ze slusnych programu stavaj odporny skladky nespravovatelnyho kodu. Hlavne abychom nahodou nemuseli udelat nejakou praci "navic" :))
-
Jo, dá se to říct i jadrnějc :-) plnej souhlas, tendle aspekt jsem nezmínil.
-
No tak tam, kde to nepotřebuju může ta metoda vrátit nějakého náhodného psa, jestli že jich má víc, nebo toho prvního, nebo psa podle datumu v kalendáři. To je fuk, doposud to smysl mělo.
Ale nemělo. Copak myslivec může vlastnit pouze jednoho psa? Nemůže. Takže prostě rozhraní myslivec nepopisovalo objekt myslivec správně. Akorát to autor programu nepotřeboval, tak mu to zatím nevadilo.
Krásné jak víme, co je správné, aniž bysme znali vlastně zadání a původní návrh.
Samozřejmě, jde to relativně bez větších úprav programu zalepit novým rozhraním a dynamic_castem, ale:
Nejedná se o žádné lepení, ale o legální techniku. Pokud vám vadí dynamic_cast, tak použijte COM+, kde máte podobnou funkci QueryInterface. Celý COM+ je na tom postavený
* místo statické kontroly datových typů za překladu mám dynamickou kontrolu typů za běhu. Tzn. ztratím veškeré výhody staticky typovaného jazyka (kontrolu za překladu a hlavně bezpečnou kontrolu - u kontroly za běhu nikdy neotestuji co všechno na dané místo může doputovat), aniž bych se ale zbavil jeho nevýhod (např. nutnost uvádět typy).
Jenže my objektoví programátoři kolikrát nevíme, jestli chceme jazyk s dynamicky typovanými objektu, nebo staticky typovanými objekty. Jenže u staticky typovaných objektů třeba zapomeňte na polymorfismus. Protože ani ten Vám překladač neohlídá. Maximálně ohlídá matchování rozhraní, ale to je tak všechno.
* v okamžiku, kdy potřebuji myslivce se dvěma psy, tak musím přepsat velkou část objektů, které s myslivcem se psem pracují - přesněji všechny, které pracují se všema psy myslivce (jinak se program nechová správně).
To je Váš názor. Já před sebou vidím návrh, kde nemusím.
Např.: Setkání s veterinářem (má naočkovat všechny psy), kontrola myslivce na hranici (kontrola, jestli má myslivec na psy papíry), setkání s rasem (chudinci pejsci), setkání s číňanem (only joking :-), my zas jíme hindům krávy :-)) atd...
Tohle v původním návrhu není. Zato vaše komponentní aplikace má takový úspěch, že každé myslivecké združení má vlastní implementaci myslivce. Zkuste jim teď říct, že v nové verzi budou muset investovat do programátora, aby to všechno přepsal?
No a tady je implementace nového rozhraní vyloženě nebezpečná, protože mi nikdo neřekne, které všechny objekty takto s myslivcem interagovaly, takže u většího programu skoro s jistotou na něco zapomenu. Takže sice budu mít "funkční program" ale přes hranice my myslivec s jedním nenaočkovaným psem projde.
No už se stalo. Asi by to člověk měl smazat a začít znova? Nebo s tím praštit úplně :-D
Proto tvrdím, že je chybou původního návrhu, když v něm myslivec nemůže mít víc psů - když je teoreticky možné, že by jich měl více. I když to program v tuto chvíli nepotřebuje a i když si pak mohu nadefinovat nové rozhraní.
Nejlepší je v tuto chvíli začít hledat viníky a strhávat jim prémie ;D
Samozřejmě někdy by implementace multipsího myslivce (obecně implemntace přesnějšího popisu reality) byla o tolik složitější, že se to nevyplatí a je lepší udělat "chybu" záměrně. To však neznamená, že člověk nedělá "chybu", jen o ní ví :-)
Pověste ho vejš, ať se houpá! ;D
Přirovnal bych to k situaci, kdy se člověk rozhodne používat Newtonovu mechaniku (a zanedbá relativitu). To je samozřejmě korektní postup, ale
- člověk musí vědět, že něco zanedbává
- měl by si bejt OPRAVDU jistej, že tu relativitu potřebovat nebude.
Pokud napíšu systém s Newtonovou teorií a následně zjistím, že potřebuji relativitu, udělal jsem chybu. Pokud napíšu program s rozhraním myslivce se psem a pak zjistím, že potřebuji multipsa, udělal jsem chybu.
Tak pánové, až příště půjdete na nějaký ten pól, tak nezapomeňte zásoby násobit dvěma.
;D ;D ;D ;D
Kecy kecy kecy!
;D ;D ;D ;D
Programoval jste vůbec někdy nějakou větší aplikaci? Nebo jen akademicky melete? Představte si, že máte komponentu Lov, kam chodí myslivci na lov. Myslivec vystřelí a zasáhne cíl a pes vyběhne a cíl přinese. Tahle komponenta běží už delší čas, má jí skoro každé myslivecké sdružení a používá se tam jednoduché rozhraní IMyslivec, který předpokládá, že k lovu využije jediného psa, který po výstřelu vyběhne, najde střelený cíl a přinese ho. Protože s každým výstřelem můžete trefit jediný cíl, stačí vám pouze jeden pes, proč se trápit s problémem, který není.
Pak se jednoho dne rozhodnu jako produktový manager vydat třeba komponentu veterinář pro kontrolu psů a zjistím, že by myslivec měl mít psu víc. A co teď? Říkám Vám rovnou, že odpovědí na Váš návrh přepsat původní rozhraní bych reagoval v lepším případě strhnutím prémií z výplaty. A ještě dlouho bych řešil "jaké paka jsem si to do firmy pozval".
Je nemyslitelné a finančně velice náročné přepisovat všechny implementace rozhraní IMyslivec. Představte si, že jste Microsoft a máte vylepšit rozhraní IDirect3D. Na světe existuje několik milioónů aplikací využívající staré rozhraní. Vy byste si lajznul takovou změnu?
Existuje tedy jediná cesta a to vytvořit nové rozhraní, IMyslivec2
class IMyslivec {
public:
...
virtual IPes *getPes() = 0;
...
};
class IMyslivec2: public IMyslivec {
public:
virtual PsiKontejner &getPsy() = 0;
virtual IPes *getPes() {return getPsy().empty()?0:&getPsy()[0];}
};
Pokud přivede myslivec psy k veterináři, bude veterinář požadovat rozhraní IMyslivec2. Dokonec už ve funkci:
void jdiKVeterinari(IMyslivec2 &m)
...můžete vyžadovat nové rozhraní. Holt starý myslivci k veterináři chodit nebudou, ale to neznamená, že by nemohli po staru lovit dál. Třeba si veterináře zajišťují svými silami.
Jaký to má výhody? Kromě toho, že nemusíte sahat do existujících fungujících komponent (po vzoru, co funguje na to nesahej), existence starého rozhrani vám umožňuje v jednoduchých situacích použít původní osvědčené rozhraní, které nevyžaduje implementaci kontejneru psů. Například když si uděláte se svým mazlíčkem doma cvičný lov. Během cvičného lovu nemusíte chodit k veterináři. Leckteré místo se Vám z jednoduší.
A dynamic_cast? Ten tam ani nemusí být
class MujMyslivec: public IMyslivec2
může jít jak na lov, tak k veterináři.
class StaryMyslivec: public IMyslivec
může jít pouze na lov.
A pokud někde obdržím referenci na objekt IMyslivec a budu ho chtít před loven poslat k veterináři, mohu to napsat takto
function PredLoven(IMyslivec &m) {
IMyslivec2 *m2 = dynamic_cast<IMyslivec2 *>(&m);
if (m2) jdiKVeterinari(m2);
jdiNaLov(m);
}
Považujete tohle řešení za prasácke?
-
Krásné jak víme, co je správné, aniž bysme znali vlastně zadání a původní návrh.
V tom je totiž krása OOP - chyby návrhu každého objektu se dá posoudit, aniž by bylo třeba znát "okolí".
(Samozřejmě okolí je potřeba pro to, aby se posoudila vhodnost toho interfacu pro interakci s okolím, ale toto posuzování má přijít teprve po posouzení správnosti daného rozhraní jako takového).
Tohle v původním návrhu není.
V původním návrhu je myslivec. Může myslivec vlastnit více psů. Ano, takových myslivců je spousta. Takže popisovat ho rozhraním, které umožní pouze jednoho psa je špatně.
Zato vaše komponentní aplikace má takový úspěch, že každé myslivecké združení má vlastní implementaci myslivce.
Ne, v mém pojetí se všichni lidi, kteří používají dané rozhraní pořádně zamyslí, navrhnou rozhraní tak, aby ho už pokud možno nebylo nutné modifikovat a používají ho. Samozřejmě ne vždy se to povede, ale protože já považuji některé návrhy rozhraní za apriori špatné, nestane se mi totéž, co Tobě:
Ve Tvém návrhu se nejdřív nabastlí myslivec s jedním psem, pak někdo přijde na to, že potřebuje myslive s více psy, tak nadefinuje druhé rozhraní, někdo další zjistí, že potřebuje myslivce s více flintami, nadefinuje nové rozhraní, pak někdo zjistí, že potřebuje myslivce s více dýmkami... nové rozhraní.....
Já, protože vím, že apriori je blbina myslivec s jednou flintou, psem či dýmkou (vždy jich může mít víc) tak nemusím žádná nová rozhraní definovat, protože už původní rozhraní funguje správně.
No už se stalo. Asi by to člověk měl smazat a začít znova? Nebo s tím praštit úplně :-D
Jo, člověk někdy udělá chybu, to je normální. Holt si prostě přizná: aha, při návrhu rozhraní myslivec jsem udělal pořádnou botu. A musí to buď přepsat (upravit rozhraní myslivce) nebo zaflikovat (udělat rozhraní myslivec2). Někdy je lepší to, někdy to, podle toho, jak je aplikace velká, kde všude se rozhraní používá, jak často se do ní šahá (čím více, tím se víc vyplatí čistší kód) atd...
U většího projektu může být dobrá cesta nadefinovat nové rozhraní, staré prohlásit za obsolete a pomalu (když se zrovna upravuje danej kus) ho z aplikace odstraňovat. Narozdíl od udržování dvou rozhraní se časem kód zas pročistí a přitom náklady budou srovnatelné (do budou spíš nižší, protože kód bude čistší).
Já neříkám, že řešení s dynamic_castem je vždy špatně. Říkám, že to, že je ho nutné použít ukazuje, že je něco špatně: většinou ten původní návrh.
---
Ve zbytku postu polemizuješ úplně s něčím jiným, než co tvrdím. Pokud už se chyba STALA, tedy pokud existuje rozhraní myslivec s jedním psem, samozřejmě může být levnější a tedy lepší řešení to opravit pomocí rozhraní myslivec2.
Co tvrdím je, že při PŮVODNÍM návrhu aplikace byla chyba udělat myslivce s jedním psem, pokud byla alespoň trochu reálná možnost, že myslivec může mít psy dva. Protože to při dalším vývoji aplikace způsobí to, že přes hranice budou chodit nenaočkovaní psi (a nebo drahý refaktoring).
---
Myslím, že to, v čem se lišíme je pragmatismus kontra idealismus. Vy tvrdíte, že pokud rozhraní vyhovuje pro dané účely v daném čase, je dobře.
Já tvrdím, že rozhraní má dobře popisovat daný objekt. Pokud popisuj dobře daný objekt, pak bude vyhovovat: a to nejen pro daný účel v daný čas, ale pro všechny účely a vždy.
Vzhledem k tomu, že jedním ze základním principů OOP je znovupoužitelnost, myslím, že můj pohled je bližší k filosofii OOP než Tvůj.
Já svého myslivce mohu použít jak při honu, tak u veterináře, tak i pro přechod hranic. Tvůj myslivec se hodí jen na ten hon (a to ještě nesmí sestřelit dvě kachny najednou, což se brokovnicí dosti často povede)...
Samozřejmě ne vždy lze postihnout úplně všechny možnosti. Ale např. v případě myslivce se psem je rozdíl v náročnosti implementace marginální (mohu tam dát ještě metodu getNejakyPes(), takže používat se to bude úplně stejně, jen holt místo pesPtr bude ve vlastnostech std::list<pesPtr>) ale v budoucnu to ušetří hafo problémů.
-
V tom je totiž krása OOP - chyby návrhu každého objektu se dá posoudit, aniž by bylo třeba znát "okolí".
(Samozřejmě okolí je potřeba pro to, aby se posoudila vhodnost toho interfacu pro interakci s okolím, ale toto posuzování má přijít teprve po posouzení správnosti daného rozhraní jako takového).
Obdivuju vaši jistotu ;D
V původním návrhu je myslivec. Může myslivec vlastnit více psů. Ano, takových myslivců je spousta. Takže popisovat ho rozhraním, které umožní pouze jednoho psa je špatně.
Můj příklad byl akademický stejně jako váš. Místo myslivce tam může být Desktop a místo psa tam může být Monitor. Doby, kdy šlo připojit k desktopu jen jeden monitor existovali a nikoho tehdy nenapadlo, že by k desktopu bylo možné připojit monitorů víc. Dodnes existují aplikace, které nepočítají s vícero monitorama.
Ne, v mém pojetí se všichni lidi, kteří používají dané rozhraní pořádně zamyslí, navrhnou rozhraní tak, aby ho už pokud možno nebylo nutné modifikovat a používají ho. Samozřejmě ne vždy se to povede, ale protože já považuji některé návrhy rozhraní za apriori špatné, nestane se mi totéž, co Tobě:
V tom případě si nechte vaše pojetí pro sebe. Nemyslím, že by mělo smysl to dál rozvijet. Každopádně trvám na tom, že to je akademická diskuze, mající k praktickému smyslu daleko. Hlavní smyslem OOP je re-usability, a tímto přístupem právě tenhle smysl jaksi narušujete.
Samozřejmě ne vždy lze postihnout úplně všechny možnosti. ....
Toho bych se držel a zkusil najít výhody OOP právě v tom, že nikdo z nás nemá patent na rozum.
-
Hlavní smyslem OOP je re-usability, a tímto přístupem právě tenhle smysl jaksi narušujete.
A jake to ma podle vas vysledky v praxi? Nechci flamovat, ale prijde mi, ze je to dost zoufale. Kdyz se podivam na opensource, tak nejlepsi reusability se ukazuje u aplikaci s textovym rozhranim (tedy dilem unixova filozofie), ktere je mozne pak ruzne volat z ruznych dalsich mist. Zatim jsem nevidel, ze by nekdo napsal OOP aplikaci (ne knihovnu - to je neco jineho), a pak nekdo jiny vzal polovinu objektu a nad tou postavil jinou aplikaci (mozna date nejaky uspesny priklad, co ja vim). Ono nakonec i s temi knihovnami - co ja vim, tak nejvic reusable jsou klasicke knihovny s C rozhranim, protoze to umi obalit prakticky kazdy skriptovaci jazyk.
Ono je to asi podobne jako s tou multiplatformnosti. Java je pry multiplatformni, ale bezi na kolika, na 6 platformach? Zatimco C program prelozite na vsem. Sliby, sliby, sliby a marketing..
-
Místo myslivce tam může být Desktop a místo psa tam může být Monitor.... Dodnes existují aplikace, které nepočítají s vícero monitorama.
Proto také člověk, který navrhoval desktop udělal chybu, když nevymyslel, že může být víc monitorů. A teď se musí flikovat.
Můžeme se k tomu postavit dvěma způsoby. Buď nad tím mávneme rukou a nebudeme to řešit a příště zas splácáme myslivcopsa, nebo to alespoň jasně pojmenujeme jako chybu, poučíme se a až budeme navrhovat svůj desktop, tak už to uděláme správně.
Hlavní smyslem OOP je re-usability, a tímto přístupem právě tenhle smysl jaksi narušujete.
??? Jaksi nechápu čím narušuji reusabilitu??? Já tvrdím, že se objekty mají navrhovat korektně, i když třeba některé jejich vlastnosti (např. možnost mít více psů) se v dané chvíli nevyužijí. A to rozhodně re-usabilitu zvyšuje a ne naopak.
To Vy tady hájíte myslivce s jedním psem, který v následném vývoji dělá problémy s re-usabilitou, ne já.
-
Proto také člověk, který navrhoval desktop udělal chybu, když nevymyslel, že může být víc monitorů. A teď se musí flikovat.
Já bych to nenazýval chybou. Zrovna tak není chyba, že původní okenní systém není třírozměrný. V tomhle jsem na straně pragmatizmu. Nač plýtvat zdroji na něco, co není dnes potřeba, a během doby se může ještě změnit.
Snaha o dokonalost je příliš nákladná činnost s pochybným výsledkem. Komplexní nadčasové věci v IT snad ani neexistují.
-
Samozřejmě, pokud je implementace "správného" rozhraní daleko dražší, pak má zjednodušení své místo. Běžně např. taky člověk používá Newtona a ne Einsteina.
Chyba je, pokud člověk ale používá Newtona, aniž by si ověřil, že toho Einsteina nebude potřebovat. A pokud ví, že ho bude, tak má např. připravit rozhraní tak, aby byl Newton rychlej a přitom Einstain použitelnej.
V našem případě to třeba znamená, u myslivce uděšlat jak metodu GetPsy(), tak i metodu GetNejakyPes() a používat zatím tu druhou. Tady to nic nestojí a ušetření práce v budoucnu je obrovské.
Samozřejmě, že predikovat např. deset let dopředu nejde. To ale přeci neznamená, že je správné a to zcela rezignovat.
-
Hlavní smyslem OOP je re-usability, a tímto přístupem právě tenhle smysl jaksi narušujete.
??? Jaksi nechápu čím narušuji reusabilitu??? Já tvrdím, že se objekty mají navrhovat korektně, i když třeba některé jejich vlastnosti (např. možnost mít více psů) se v dané chvíli nevyužijí. A to rozhodně re-usabilitu zvyšuje a ne naopak.
To Vy tady hájíte myslivce s jedním psem, který v následném vývoji dělá problémy s re-usabilitou, ne já.
[/quote]
No tím že změníte rozhraní musíte reimplementovat všechny objekty, nemůžete tedy znovu-použít to co už máte napsáno ve smyslu objektového. Já vím, že vy namítnete, že ta reimplementace se může omezit jen na vhodnou variantu find-replace v textovem editoru, ale tak jednoduché to vždycky není. Spoléhat se při programování na schopnosti editoru je vyloženě špatné.
Proč používáme konstanty, když mohu v celém programu jednu konstantu za jinou nahradit pomocí editoru?
-
Ondra.novačisko.cz
já si nejdřív dovolím trochu hnidopišství :
class IMyslivec2: public IMyslivec {
int akt_pes;
public:
void selectPes( int id = 0 ) { if( ( get_psy( ).size( ) > id ) && (0 >= id ) ) { act_pes = id }; }
virtual PsiKontejner &getPsy() = 0;
virtual IPes *getPes() {return getPsy().empty()?0:&getPsy()[ act_pes ];}
};
... nikde v zadání není psáno ni o tom, že myslivec co má víc psů bude používat jen jednoho - pak by taková úprava byla IMHO trochu o zbytečná (ještě tam chybí informace o tom, kolik těch psů vlastně má) :-)
Vaše řešení třídy myslivec není přímo prasácké, určitě je funkční a v mnoha situacích určitě lepší než přepisovat celou knihovnu, ale mě to přijde trochu ... násilné.
Mě kdysi učily, že když mám skříň (myslivce) mohu do ni dát jeden šálek (může mít psa). Pokud ovšem nikde není napsáno, že do této skříně mohu dát jen a pouze jeden šálek (tedy myslivec smí mít pouze jen jednoho psa) musí jit do skříně dát více šálku (každý myslivec může mít psů více). A hlavně nám bylo zdůrazněno, že musíme počítat s tím, že dřív či později bude někdo chtít dát do té skříně šálku hned dva, deset, ... (tedy, myslivec půjde na hon s celou smečkou). Nemluvě o tom, že do skříně mohu dát také talíře, sváteční košile, nebo sbírku angličáků (tedy myslivec může mít kokršpaněly, jezevčíky, ... nebo třeba pudly). Popřípadě od všeho něco. Vyhoví třída myslivec těmto požadavkům? Takže otázku "Koho jsem si to sakra do firmy nasadil?", bych si položil při pohledu na nedodělanou bázovou třídu IMyslivec.
a co to skusit už od začátku třeba takto nějak "
class z_JedenCokl {
...
IPes* get_Pes( ); /// Pes ;-)
};
class z_PsiSmecka {
...
int no( ) { ... } /// Pocet ratafaku
void AktualniPes( int id ) {...} /// Vyberu si psa ze smecky
IPes* get_Pes( ) { ... } /// A budu s nim neco vyvadet
}
template <typename T> class IMyslivec : public T {
/// Metody rozhrani myslivec
JdiNaLov( IHonidba *h );
};
Tak to bychom měly :) Myslivce máme jasně definovaného, a nijak nezasahujem do jeho deklarace a přesto mohu určit s jakymi a kolikati psy bude konkretni myslivec fungovat :
class z_NoPes { };
...
IMyslivec<zasada_JedenCokl> *HajnyA = new IMyslivec<z_JedenCokl>;
IMyslivec<z_PsiSmecka> *HajnyB = new IMyslivec<z_PsiSmecka>;
IMyslivec<z_NoPes> *HajnyC = new IMyslivec<z_NoPes>;
...
IHonidba *hon;
Tomuto způsobu se říká zásady. A jde v podstatě o to, že vaše šablona myslivec určuje základní rozhraní a chování (řekl bych jakýsi rámec) objektu. Zásady jsou potom malé moduly, vyhovující přesně vaším požadavkům, kterými doplníte možnosti původního objektu. Nejde tu to jak jsou jednotlivé třídy implementovány, ale o jejich rozhraní (proto jsem se ze své vrozené lenosti neobtěžoval dopisovat implementaci metod, zde je opravdu nepodstatná) :
if( VeterinarniKontrola( HajnyA->get_pes( ) ) != TRUE ) {
....
}
...
for( int i = 0; i != HajnyB->no( ); i++ ) {
HajnyB->AktualniPes( i );
if( VeterinarniKontrola( HajnyB->get_Pes( ) ) != TRUE ) {
/// Neco s tim udelej
...
}
}
Výhodou je to, ze programátor primo až při psaní kódu rozhoduje co bude daná třída podporovat, ale myslivec bude vždy myslivec - i presto, ze žádného psa mýt nebude.... Navíc, v zásadách se zásadně nepoužívají virtuální metody, takže nedochází k zbytečnému nafukování výsledného binárního kódu, když změníte zásadu za jinou s jiným rozhraním, sám překladač vás upozorní na změny a nakonec, zásady jsou velice variabilní, takže je lze různě řetězit, nebo kombinovat....
...
HajnyA->JdiNaLov( hon );
HajnyB->JdiNaLov( hon );
HajnyC->JdiNaLov( hon );
...
-
Teorie pěkná, ale my jsme ve fázi, kdy máme rozhraní IMyslivec (I znamená Interface a má všechny metody abstraktní). Taky asi nešlo o šablony, protože by to mělo být aplikovatelné i na Javu a jiné jazyky :-)
Takže mám výhradu i k "Traits", protože původní rozhraní Traits nemá a tedy to opět znamená přepsat všechno (i kdyby se tam daly defaultní Traits) ty šipítka se tam psát musí. Možná přes nějakou kombinaci typedefů. Ale jak jsem psal, o to tady nešlo).
Řešení se psí směčkou na místo psa ale beru, je to další řešení, nicméně problém se přesouvá z myslivce na psa. Pokud rozrhaní psa má metody štekej a přines kořist, pak u štekej si dokážu představit, že budou štekat všichni psy, ale jak smečka donese kořist to nevím... ale určitě by to nějak šlo. ;D
-
Kdo je v té fázi? Já ne :-) Já bych od začátku udělal myslivce s x psy, celou dobu tvrdím, že už při implementaci IMyslivec se měl udělat s více psy, i když byl aktuálně potřeba jen jeden.
To, že když už to někdo zprasil (neuvědomil si, že psů je možné mít více), tak že to někdy nejde s rozumnými (tzn. odpovídajícími zisku) náklady přepsat nepopírám. Akorát tvrdím, že výsledné řešení bude horší (méně čitelné, s větším rizikem chyb a horším laděním), než kdyby byl IMyslivec navržen pořádně od začátku.
--
Udělání ze psa multipsa IMHO není příliš dobrý nápad - veterinář ho naočkuje, naočkují se tedy všichni psy. Jenže veterinářovi ubyde jen jedna vakcína. A máme zas problém. Pokud má mít myslivec smečku, může jít o dobré řešení (některé pokyny se dají dát opravdu celé smečce), ale musí být všem jasné, že je to smečka (tak to myslím Tiger myslel), a ne ji maskovat za psa.
--
Tiger: To pravidlo se šálkami se mi líbí, to by se mělo tesat do kamene (a těma kamenama pak mlátit po hlavách začínající programátory) :-)
-
Logiku, když pořád trváte na to špatném návrhu už od začátku, tak já jako produkťák nyní budu chtít, aby k veterináři nechodili jen myslivci, ale všichni vlastníci psa.
Co uděláte teď s myslivcema?
-
Teorie pěkná, ale my jsme ve fázi, kdy máme rozhraní IMyslivec (I znamená Interface a má všechny metody abstraktní). Taky asi nešlo o šablony, protože by to mělo být aplikovatelné i na Javu a jiné jazyky :-)
Není to teorie :) Používá to knihovna Loki (Alexandrescu - doufám, že to jméno píšu správně), a klientské rozhraní zásad IMyslivec<> lze považovat též za určitou abstrakci. Záleží jen na přístupu. nicméně sám jsem zásady už párkrát ke své spokojenosti použil.
Požadavku na portabilitu do jiných jazyků jsem si nevšiml, reaguji jen na diskuzi kolem tříd které "umějí běžně více rohraní" - která se vyvinula až do tohoto příkladu. Jak vidíte rozhraní založené na zásadách také, a navíc se obejde bez polymorfních tříd (zasady nesmí být virtuální a nesmějí ani takové funkce obsahovat), nepotřebují k tomu žádný z konverzních "cast" operátorů ( oproti dynamic_cast<>( ) má tu výhodu že není omezena jen na přímou linii hierarchie dědičnosti, a oproti reinterpret_cast<>( ) je přenositelný a korektní )
Takže mám výhradu i k "Traits", protože původní rozhraní Traits nemá a tedy to opět znamená přepsat všechno (i kdyby se tam daly defaultní Traits) ty šipítka se tam psát musí. Možná přes nějakou kombinaci typedefů. Ale jak jsem psal, o to tady nešlo).
"Traits"? Jako zvláštnosti? Žádné nevidím... ;D
Ano, ale píšu - muselo by se to tak navrhnout od začátku. Chybu celého tohoto příkladu vidím už v počátečním návrhu. S dobrým návrhem by bylo řešitelné, aby k veterinářovy chodily všichni lidé - nejen majitelé psa, ale trochu jinou metodou ;) , samozřejmě bez zásahu do třídy IMyslivec.
Představte si, že by produkťák si namyslel, že chce mimo požití více psů při honu taky možnost střílet z různých zbraní a jejich kontrolu, a k tomu měnit uniformu a před honem ji nechat protáhnout čistírnou. Ano s Vaším řešením to upravit lze a rychle, jenže nedej bože aby se tam zanesla chyba a nedej bože aby se to za rok začalo opravovat znova.
Běžnou chybou programátorů v C++ je, že se totiž hodně rádi nechávají unést myšlenkami OOP, ale (už jsme se toho jednou dotkly) C++ je typový jazyk - a to je jeho síla....
Řešení se psí směčkou na místo psa ale beru, je to další řešení, nicméně problém se přesouvá z myslivce na psa. Pokud rozrhaní psa má metody štekej a přines kořist, pak u štekej si dokážu představit, že budou štekat všichni psy, ale jak smečka donese kořist to nevím... ale určitě by to nějak šlo. ;D
och sorry mea culpa. poslední kód měl vypadat takto (i tak se občas projevuje únava :) ):
HajnyA->JdiNaLov( hon );
HajnyB->AktualniPes( 1 ); /// Predpokladam, ze jich ma ve smecce vice nez jednoho :)
HajnyB->JdiNaLov( hon );
HajnyC->JdiNaLov( hon );
Jinak u zásad jde o to, ze záleží pouze na Vás jak, s jakými psi bude třída IMyslivec operovat ve Vašem kódu. Nabízejí pouze možnost dodat vhodné rozhraní určité třídě a to až při jeho ptřebě. Já tedy vytvořím (navrhnu) Myslivce. Vy jej použijete s multipsem (se vším co s tím souvisí) a třeba Logik jej použije bez psa. Ale myslivec bude vždy myslivec. Veterinář kontroluje psa, ne myslivce, roto taky bude fungovat korektně. Myslivec půjde na hon a pošle tam konkrétního psa - taky ok. Je to jen a pouze rozhraní - jaké bude a jak jej použijete, je už jen čistě Vaše věc. Rozumíme si?
-
[Logik] Nemyslím, že by Ondra byl začínající programátor (nevypadá na to :D ), ale i tak díky.
Faktem je, že myslet na všechny aspekty nějaké třídy je mnohdy opravdu téměř nadlidský úkol a zohlednit je v nějaké konkrétní (nedej bože abstraktní) deklaraci je potom sisifofský úkol. Jenže pokud se nezvládne už samotný počáteční návrh, je potom dodatečná úprava (pouze prostředky jazyka - nikoliv úpravou původní implementace) hotová pohroma :'(
Proto je kolikrát podle mě asi nejlepší to co navrhuješ - pokud to jde, upravit, otestovat, odladit a poslat patch. V případě DX ti však nezbývá asi jiná možnost, než násilím nabalovat na původní implementaci další a další vrstvy a modlit se aby to někde neškobrtlo :(
-
Není to teorie :)
Tahle diskuze je teorie ... :)
Používá to knihovna Loki (Alexandrescu - doufám, že to jméno píšu správně), a klientské rozhraní zásad IMyslivec<> lze považovat též za určitou abstrakci. Záleží jen na přístupu. nicméně sám jsem zásady už párkrát ke své spokojenosti použil.
Já to znám, knihu mám přečtenou, knihovnu rozebranou do mrtě, některé věcí jsem převzal do svých projektů. Ale nejsem velký zastánce nadužívání šablon, pokud to nemá smysl. A nemá to smysl tam, kde nepotřebuju honit výkon na úkor čitelnosti a flexibilnosti. Prostě běžná rozhraní mám klasicky abstraktní s virtuálními metodami a používám šablony opravdu tam kde to je třeba. Třeba tam, kde si se standardním rozhraním nevystačím, například proto, že rozhraní nejde ani popsat pomocí vyjadřovacích prostředků C++ (například, "objekt musí mít defaultní konstruktor", atd)
Požadavku na portabilitu do jiných jazyků jsem si nevšiml, reaguji jen na diskuzi kolem tříd které "umějí běžně více rohraní" - která se vyvinula až do tohoto příkladu. Jak vidíte rozhraní
No v Javě je normální že třída "extends" jinou třídu a "implements" pět rozhraní. I více. V C++ sice pro rozhraní klíčové slovo nemáme ale vícenásobnou dědičností lze simulovat z větší části "implements"
založené na zásadách také, a navíc se obejde bez polymorfních tříd (zasady nesmí být virtuální a nesmějí ani takové funkce obsahovat), nepotřebují k tomu žádný z konverzních "cast" operátorů ( oproti dynamic_cast<>( ) má tu výhodu že není omezena jen
na přímou linii hierarchie dědičnosti, a oproti reinterpret_cast<>( ) je přenositelný a korektní )
Prosím, při přetypování v hierarchii nedymaickou cestou doporučuj static_cast. reinterpret_cast nikdy!
"Traits"? Jako zvláštnosti? Žádné nevidím... ;D
Přislo mi, že v knize pod slovem "Zásada" se rozumí Traits. Jinak Trait se překládá jako "rys" (traits jsou rysy). Nevím. každý máme jinou terminologii a úplně nejhorší jsou překlady od různých autorů.
Jinak rozhraní program nic nestojí. Implementace rozhraní stojí jednu tabulku VT navíc a dynamic_cast je asi nejnáročnější operace, která tam je (a taky není potřeba vždy).
Používání vícero rozhraní přibližuje C++ spíš k jazykům s dynamickým typování, což se občas může hodit. Sice se s tím asi nedocílí takové výkonnosti jako u šablon, ale je to jako se vším. Otázka ceny.
Psát program celý v šablonách s tím, že místo konkrétního rozhraní tam mám všude T... to se samozřejmě dá, ale člověk se musí připravit na jiné obtíže, například že díky neexistuence konceptů bude často chyby hledat v nějaké desáté úrovni vnoření a louskat hlášky GCC, proč zrovna tenhle objekt nejde do funkce použít a co mu ještě chybí, aby to šlo (třeba nemá defaultní konstruktor)
-
Proto je kolikrát podle mě asi nejlepší to co navrhuješ - pokud to jde, upravit, otestovat, odladit a poslat patch. V případě DX ti však nezbývá asi jiná možnost, než násilím nabalovat na původní implementaci další a další vrstvy a modlit se aby to někde neškobrtlo :(
No a teď si vem, že máš v požadavcích BINÁRNÍ kompatibilitu. Nicméně nevidím nutnost simulovat stará rozhraní nějak zásadně. Vždycky to funguje tak, že se simulace šoupne do jiného zdrojáku aby se nepletla s originální obsluhou... a dál se na ní nesahá, jen se pak nakonec přilinkuje. Koho zajímá, že simulace volá simulaci vola simulaci a nakonec volá původní obsluhu? Smyslem je "aby to fungovalo" a ne aby to fungovalo efektivně.
-
No původně to mělo bejt třeba takhle:
IPes {};
IMyslivec
{
set<IPes> getPsy();
}
Takže pokud budu potřebovat, by vši lidé chodili k veterináři, tak to trochu upravím:
IZvire {};
IPes extends IZvire {};
IMajitelZvirat
{
set<IZvirata> getZvirata();
};
IMyslivec extends IMajitelZvirat
{
set<IPes> getPsy();
}
V Izvire zadefinuju potřebné metody (popř. je přesunu z IPes). Ve všech psech a myslívcích budu muset sice nadefinovat potřebné metody - což jestli je pořádek v kódu neni problém - ale zas budu mt jistotu, že žádný zvíře nebude naočkovaný.
Pokud bych potřeboval očkovat pouze psy, tak je to ještě jednodušší - udělám rozhraní IMajitelPsu, tam přesunu metodu getPsy z myslivce a myslivce z ni podědím. Všechny lidi pak podědím z majitelů psů. Tady ani dokonce nemusím upravovat ani myslivce, ani psa, pouze ostatní lidi, kteří musí být schopní veterinářovi poskytnout své psy...
Je ještě druhá varianta, která může být někdy užitečná - z IMajitelZvirat nepodědím všechny lidi, ale pouze opravdové majitele zvířat. Na hranicích či u veterináře se pak pomocí RTTI se zeptám, zdali je to majitel zvířat.
To je ale úplně jiná situace, než přetypování IMyslivce na IMyslivce2, protože zde dotaz pomocí RTTI v podstatě supluje metodu mamZvirata(). Buď tedy mám zvířata, nebo neimplementuju toto rozhraní - tercium non datur.
Naopak u myslivců, jak bude vypadat veterinář? Ten se zeptá: jseš IMyslivec? Jestli jo, naočkuje jednoho psa. Pak se zeptá jsi IMyslivec2? Jestli jo, naočkuje všechny psy. A jeden dostane pigáro dvakrát. Jinými slovy: u mého přístupu Majitel zvířat je právě ten, kdo implementuje rozhraní IMajitelZvirat. U Tvého řešení to tak neplatí, může implementovat rozhraní IMyslivec1, IMyslivec2, IMyslivec789 atd...
Jinak, to začínající programátor nebylo na Tebe :-)....
u Tebe už je evidentně pozdě :-D :-D (no offense, only joking :-))
-
Já nevím, ale pořád se točíme v kruhu. Vy neustále dokazujete, že se umíte vyhnout multi-interfacům, že nutíte uživatele vašeho interface neustále přepisovat své objekty, které ho používají. Zapomínáte, že uživatelé mohou být různí, v závisloti na tom, jak populární Vaše knihovna je (po takovýhle tanečcích asi těžko :D )
Už vůbec se děsím toho, když mi napíšete "vydám patch" a je to. Nevydáte. Patch Vám nepomůže, každý objekt, který rozhraní používá je jiný. Navíc to takhle prostě fungovat nemůže a důkaz je vidět zrovna ve vývoji linuxu. Místo toho, aby se zachovala nějaká základní kompatibilita, tak každý jádro je jiný, po binární stránce úplně, po zdrojákový stránce sice méně často, ale i tak to znamená, že staré ovladače s novým jádrem prostě nepřeložím. Nové ovladače nejsou (autor zaniknul, nebo se věnuje něčemu jinému). žádný patch mi nepomůže, neboť bych si ho musel napsat sám. A to jen proto, že Linus neuznává OOP, a to ani z pohledu techniky programování, když už to musí psát v Cčku a jako Vy, trvá na tom, že stará rozhraní se musí aktualizěovat a navazující moduly se prostě musí přepsat.
Nejsem si jist, jestli tohle je prostě ta správná cesta. Jistě někdy je třeba udělat radikální řez a vydat Myslivecky Informační Systém 2, který není kompatibilni s verzí 1. Chvíli budete muset udržovat a aktualizovat obě verze, než většina klientů přejdou na verzi 2. A to ta verze 2 musí být fakt dobrá, aby se to těm lidem vyplatilo (přesvědčte linuxové uživatele, aby svá kradená XPčka vyměnla za kradené Sedmičky)
Celý spor vznikl tím, že jsem chtěl dokázat,že není třeba změnu v rozhraní zajišťovat ve všech částech programu, v reakci na opačný názor který tu zazněl jako hlavní kritika OOP (zajímavý je, že to platí i pro klasické ne-OOP programování, viz ten Linux)
Já jsem argumentoval tím, že vždycky se dá vyrobit nové rozhraní. A abych se nedržell u země, vždycky se dá vyrobit úplně nová hierarchie.
Nebo co komu vadí, když můj myslivec bude mít takovou deklaraci
class MujMyslivec implements IMyslivec, IMyslivec2, IKlientVeterinare
Tyhle změny lze provádět inkrementálně, vždy, když chci přidat novou funkcionalitu. Mohu ale samozřejmě nemusím, pokud mi to vyhovuje. Dávám ti, klientovi určitou svobodu v rozhodování. Samozřejmě jde i o cíl systému, který píšu. Pokud z pozice despotického vládce nad mým kódem vydám nařízení po vzoru EU, že každý myslivec musí se svými psy chodit k veterináři, tak si mohu dovolit vynutit si toto rozhraní už na IMyslivec a mám jistotu, že ti, co k veterináři nechodi si prostě v nové verzi neškrtnou, dokud si ty svý myslivce neopraví.
Připomínám, že příklad s myslivcem je jen akademický příklad. Místo myslivce si lze představit třeba rozhraní pevného disku a můžeme se hádat, jestli do tohoto rozhraní přidáme příkaz na označování prázdného bloku pro SSD disky nebo ne. Pokud to totiž uděláme, rozbijeme všechny současné diskové ovladače, pokud k tomu zřídíme nové rozhraní, staré ovladače budou fungovat.
A já považuju programovací styl předpokládající budoucí vývoj stejně důležity jako vy, s tím, že já už dávno vím, že nejsem věštec. Nesnažím se uhodnout, kam půjde vývoj. Nemohu k tomu abych sečetl dvě čísla popsat celý matematický systém, abych pokryl všechny možné budoucí změny... co když místo čísel budem sčítat matice, nebo rovnice?
-
Vraťme se, k začátku diskuse. Tam já jsem tvrdil, že jeden konkrétní navržený interface je dobře, protože je velmi špatně rozšiřitelný. A když ho budu chtít rozšířit. Jestli jste to pochopil jako kritiku OOP, tak si to přečtěte ještě jednou, nebyla to kritika OOP, ale kritika využití dědičnosti na místě, kam prostě dědičnost nepatří. To není nic proti OOP, to je naopak pro OOP. A demonstroval jsem, že z určitých důvodů je ten návrh špatně.
Vy jste na to odpověděl, že není špatně, protože to jde "opravit" pomocí nového rozhraní. A já pouze tvrdím, že to sice jde, že to je někdy i nejlepší řešení, ale že bylo špatně, když se to neudělalo pořádně hned.
A abych se nedržell u země, vždycky se dá vyrobit úplně nová hierarchie.
Ano jde. Jde psát program pomocí spousty goto. Jde o to, jak bude takový program čitelný. A rozhodně program s méně univerzálními enterfacy bude čitelnější, než program, kde je pro každou věc nadefinovaný nový interface.
Interface je abstrakce, zobecnění. Pokud tedy pro každou věc nadefinuji nový interface, tak kde je ta abstrakce?
Nebo co komu vadí, když můj myslivec bude mít takovou deklaraci
No vadí tomu spousta věcí. Např. chci objekt na lov. Mám tam poslat IMyslivce,nebo
IMyslivce2?
Chci napsat nové rozhraní na kontrolu všech psů (např. úředníkem). Mám dvě možnosti: První je využít existující rozhraní. Tady ale místo jednoho rozhraní IMajitelZvirat musím kontrolovat rozhraní IMyslivec, IMyslivec2, IKlientVeterinare (a deset dalších).
Navíc, mezi těmi rozhraními není vztah, co když přijde někdo implementující IMyslivec i IKlientVeterinare? Mám kontrolovat objekt pouze skrze jedno z nich, nebo skrze obě? Jak vým, jestli myslivec chodí k veterináři s kočkou, nebo svým mysliveckým psem? Ve výsledku napíšu hromadu zbytečnýho kódu řešící existenci deseti duplicitních rozhraní.
Druhá možnost je napsat nové rozhraní IKontrolovanýClovek. Jenže todle rozhraní nikdo neumí, takže nic nezkontroluji, aniž bych přepsal všechny objekty, které chci kontrolovat - a právě proti tomu brojíte.
No a pak je třetí možnost, že mam v kódu pořádek, IMyslivec byl od začátku poděděnej od IMajitelZvirat, toto rozhraní používá i veterinář a když chci napsat kontrolu úředníkem, opět využiji to samé rozhraní IMajitelZvirat.
Toto řešení je IMHO nejlepší, nejčistší, s nejmenší pravděpodobností výskytu chyb. Také nejvíce odpovídá principu OOP, protože podporuje reusability.
Vy neustále dokazujete, že se umíte vyhnout multi-interfaců
Už jsem tu jednou psal, nevylučuji, že to řešení s dynamic_castem nebude někdy nejlepší možné. Ani nevylučuji, že se mi návrh nepovede a multi-interfacům se nevyhnu. To ale přeci nepovyšuje bastl na standard.
Když chci přejít řeku a vím, že se tam nebudu vracet, stačí mi doprostřed naházet šutry a přeskákat. To ale neznamená, že mohu prohlašovat, že ty naházené kameny jsou most. Je to bastl - i když v dané situaci nejlepší řešení.
Stejně tak když na 1GB harddisku na data udělám 100MB partition, protože si blbě přečtu velikost - tak pak může být nejlepším řešením udělat ze zbylého místa druhou partition (např. proto, že data nemám kam odzálohovat). To ale přeci neznamená, že by to měl být standardní postup, nebo že řešení se dvěma partition je nejlepší.
co když místo čísel budem sčítat matice, nebo rovnice?
Právě proto existují určité zásady, jak navrhovat rozhraní - aby se minimalizovala práce při rozšiřování funkčnosti programu. A podle těchto zásad jdou rozhraní posuzovat. Ano, je možné, že budu mít problém, i když ty zásady dodržím, ale ten problém nebude tak často a bude zpravidla daleko jednodušeji řešitelný.
Jednu z těchto zásad sem postnul Tiger. A jelikož IMyslivec tuto zásadu porušuje, jde toto rozhraní označit jako špatně navržené.
-
Ja bych byl rad, kdyby mi ondra.novacisko (nebo jiny zastance OOP) odpovedel na moji otazku, jak podle jeho zkusenosti OOP podporuje reusability. Opravdu me to zajima.
-
Logik: Já mám neblahé tušení, že nevíte co rozhraní je. Zvlášť po tom, co se ptáte, kterého myslivce máte poslat na lov. To je jako kdyby jste se ptal, u televize, která má dva video vstupy, kompozitní a SCART, kterým vstupem připojíte video? No samozřejmě tím, který podporuje to video. A pokud podporuje oba, můžete si vybrat.
U úředníka kontrolujícího psy můžete mít také vlastní rozhraní. Je to rozhraní, kterým komunikuje úředník s myslivcem. Dokonce kolikrát ta rozhraní bývají dvě. Někdy musí myslivec komunikovat s úředníkem.
Rozhraní není objekt, je to komunikační protokol. Rozhraní může objekt implemenatovat buď přímo, nebo prostřednictvím proxy objektu, který vystrčí místo sebe. Třeba že by místo sebe na lov poslal kolegu s jedním psem.
A pak jsem pochopil, že Vás trápí název rozhraní. Občas se stane, že během vývoje rozhraní svůj název přestane dokonale vyplňovat. Ale název je jen idenitifikace a nemusí mít význam, Klidně jsem místo IMyslivec mohl vymyslet rozhrani IA8b92cd, jehož specialitou je, že prostřednictvím něho se správce honu dozvídá stav myslivce a jeho psa během honu (třeba polohu myslivce a psa a úspěšnost a podobně). Jiný účel rozhraní nemá.
JS: Re-usability znamená, že z libovolného projektu mohu vykostit libovolnou třídu a tato třída pak může fungovat v jiném projektu. Každá třída může fungovat jako samostatný jedinec nezávisle na okolí. Tuhle vlastnost velice často využívám. Například mám třídu, která maluje na obrazovce bubliny a tuto třídu mám v každém projektu, kde pořtebuju bubliny. V jedné aplikaci jsem si napsal třídu na stahování souboru po internetu. Pak jsem to použil v každém dalším projektu. Jiný příklad, v jedné aplikaci jsem měl ikonku v systray a k tomu napsaný objekt zajišťující obsluhu události s tou ikonou, nastavování ikony a dalších věci. Najednou jsem to potřeboval někde jinde. Tak jsem prostě ty dva soubory (h + cpp) nasdílel do toho nového projektu a bylo to.
Nedokážu si představit, že bych psal jakoukoliv aplikaci tak, aby to byl jeden monolitický návrh. Vždycky to je obrovské množství samostatných spolupracujícíh modulů a jen jedna třída je tam specifická, která to celý zastřešuje. A to je třída tvořící vlastní aplikaci.
Je na místě říct, že OOP podporuje re-usability, ale nemůžu říct, že je jejím garantem. Pořád to záleží na schopnosti programátora a na dobrém návrhu. Nicméně těch pravidel, které člověk musí v projektu dodržet je méně, než u klasického ne-OOP návrhu a navíc to programátora motivuje objekty nezávisle. Nehledě na tom, že člověk snáze navrhne malou černou krabičku kterou pak lépe propojí s jinýma černýma krabičkama, než navrhovat jednu velkou černou krabičku, do který se radši už potom nikdy nepodívám (abych se nezděsil)
-
... nejsem velký zastánce nadužívání šablon, pokud to nemá smysl. A nemá to smysl tam, kde nepotřebuju honit výkon na úkor čitelnosti a flexibilnosti. Prostě běžná rozhraní mám klasicky abstraktní s virtuálními metodami a používám šablony opravdu tam kde to je třeba. Třeba tam, kde si se standardním rozhraním nevystačím, například proto, že rozhraní nejde ani popsat pomocí vyjadřovacích prostředků C++ (například, "objekt musí mít defaultní konstruktor", atd)
....
Psát program celý v šablonách s tím, že místo konkrétního rozhraní tam mám všude T... to se samozřejmě dá, ale člověk se musí připravit na jiné obtíže, například že díky neexistuence konceptů bude často chyby hledat v nějaké desáté úrovni vnoření a louskat hlášky GCC, proč zrovna tenhle objekt nejde do funkce použít a co mu ještě chybí, aby to šlo (třeba nemá defaultní konstruktor)
...
Jinak rozhraní program nic nestojí. Implementace rozhraní stojí jednu tabulku VT navíc a dynamic_cast je asi nejnáročnější operace, která tam je (a taky není potřeba vždy).
...
No a teď si vem, že máš v požadavcích BINÁRNÍ kompatibilitu. Nicméně nevidím nutnost simulovat stará rozhraní nějak zásadně. Vždycky to funguje tak, že se simulace šoupne do jiného zdrojáku aby se nepletla s originální obsluhou... a dál se na ní nesahá, jen se pak nakonec přilinkuje. Koho zajímá, že simulace volá simulaci vola simulaci a nakonec volá původní obsluhu? Smyslem je "aby to fungovalo" a ne aby to fungovalo efektivně.
Já nejsem příznivcem nadužívání, nebo protěžování čehokoliv. Všechno co bylo vymyšleno, jsou jen nástroje, které mají za úkol mi nějak ulehčit, zefektivnit, nebo umožnit práci jejich použitím - proto tvrdím, že je pitomostí vždy a všude tvrdošíjně prosazovat objektový, nebo naopak procedurální přístup. To jsou extrémismy a ty jsou od přírody špatné. Nicméně ty nástroje existují a je zas na druhou stranou škoda jich nevyužít, v případech kdy je to vhodné - a ty případy zas určuje konkrétní člověk (lidé), který daný kód tvoří.
Souhlasím s Logikem, že ten akademický příklad je už od začátku špatný, a takový kód je nejlepší omlátit autorovy o hlavu, a pak jej celý přepsat do použitelnější podoby. Jednou z vhodných možností je použít zásad. Žel bohu v praxi (a tady souhlasím s Vámi) je však pro toho kdo s ním pracuje nejlepší na něj nabalit další vrstvy a pak děj se vůle boží. To že tu vrstvu oddělíte do externích modulů, či jakkoliv jinak, však neřeší základní nepříjemnost celého tohoto postupu, a to tu že celou věc znepřehledňuje, zanáší do ní spoustu nových stavů a potencionálních chyb. Vy se v tom možná vyznáte, ale jakmile někdo projekt převezme po Vás, může si jít hodit smyčku (bez urážky, nemyslím tím nic špatného směrem k Vám, vidím to prostě tak i z vlastní zkušennosti).
Celé to připomíná přístup javovských programátorů, kde si vezmete jednu konkrétní funkci z jedné konkrétní knihovny a než se dostanete k tomu co a jak to dělá, prolezete mraky dalších knihoven, vrstev a nadstaveb... A to je špatně (bez ohledu na to zda to někdo řeší či ne, a že to někoho určitě bude zajímat, na to vemte jed ).
Jinými slovy, Vaše řešení podle mě problém se neřeší, jen obchází. Neřeší se nemoc, pouze se odstraňují symptomy.
Navíc je omyl, si myslet, že používání šablon může vést k vyššímu výkonu. Mám zkušenosti i s opakem. Hlavně papačka je to ladit - skoušel jste si někdy seznamy typů z Loki? Krása, ne? (Pravdou je, že tu chybu jsem si tam zanesl sám v jedné ze tříd, ale než jsem ji našel, měl jsem okousaný všechny nehty, tužku, nervy v kýblu a o třicet procent víc šedin) ;D
Prosím, při přetypování v hierarchii nedymaickou cestou doporučuj static_cast. reinterpret_cast nikdy!
Operátor reinterpret_cast<>( ) jsem uvedl z důvodu, že umožňuje převod i na jiné nesouvisející struktůry - může v tom být do jisté míry podobnost se zásadou, avšak u zásady to není účel. já jej osobně nevyužívám (nevěřím buď jemu, nebo sobě - vysledek je stejný :D ). Ovšem pokud je někdo tak dobrý, proč ne... ;)
Přislo mi, že v knize pod slovem "Zásada" se rozumí Traits. Jinak Trait se překládá jako "rys" (traits jsou rysy). Nevím. každý máme jinou terminologii a úplně nejhorší jsou překlady od různých autorů.
Pokud to dobře chápu, pak rys je něco mezi strategií a zásadou. Poskytuje sice šabloně nové rozhraní, ale jeho zaměřením je interní implementace nějaké funkčnosti - tedy tak nějak jsem to pochopil...
Používání vícero rozhraní přibližuje C++ spíš k jazykům s dynamickým typování, což se občas může hodit. Sice se s tím asi nedocílí takové výkonnosti jako u šablon, ale je to jako se vším. Otázka ceny.
No, otázka je zda se s tou cenou počítá i do budoucna. Pokud někdo navrhne skříň do níž dám pouze jede hrnek, nebo myslivce, který může mít jen jednoho psa a finito, pak si nejsem tou cenou až tak jist.... Pokud je kód ještě navíc uzavřený, myslím že to může to být v budoucnu velmi drahá záležitost. A určitě sám ze zkušenností víte, že peníze mohou být v takovém případě ještě pořád to nejmenší. Ale - je to asi jen věc pohledu...
-
důkaz je vidět zrovna ve vývoji linuxu. Místo toho, aby se zachovala nějaká základní kompatibilita, tak každý jádro je jiný, po binární stránce úplně, po zdrojákový stránce sice méně často, ale i tak to znamená, že staré ovladače s novým jádrem prostě nepřeložím. Nové ovladače nejsou (autor zaniknul, nebo se věnuje něčemu jinému). žádný patch mi nepomůže, neboť bych si ho musel napsat sám. A to jen proto, že Linus neuznává OOP, a to ani z pohledu techniky programování, když už to musí psát v Cčku a jako Vy, trvá na tom, že stará rozhraní se musí aktualizěovat a navazující moduly se prostě musí přepsat.
Už zase? Linux a C++ je Vaše oblíbené téma, že ano? ;D
otázka kompatibility není o OOP (ať už jej Linus uznává, či ne), ale např. o tom, zda je výhodné tu kompatibilitu sebou nést nebo ne. Navíc všechno je to úhlu pohledu.
Vemte v potaz, že kernel se vyvíjí neuvěřitelně rychle. Nové technologie, podpora nového hardware, nové funkčnosti. K tomu se musí odebírat ty které se neosvědčily, nebo jsou zastaralé (já netvrdím, že je to ideální, ale dělají to lidé a podle mě jim to jde docela dobře - ve srovnání s konkurencí). Dovedete si představit ten bordel, kdyby jste chtěl v takovém stavu dneska zpětnou kompatibilitu třeba s prvními jádry řady 2.6?
A to se pro jistotu nezmiňuji ani o tom sajrajtu, co by vznikal ( zbytečně a na systémové úrovni k tomu), kdyby se řešila každá chybějící funkčnost, nebo chybný návrh, pouze způsobem který navrhujete výše...
A navíc, funguje to - už víc než dvacet let.... ;)
-
To že tu vrstvu oddělíte do externích modulů, či jakkoliv jinak, však neřeší základní nepříjemnost celého tohoto postupu, a to tu že celou věc znepřehledňuje, zanáší do ní spoustu nových stavů a potencionálních chyb. Vy se v tom možná vyznáte, ale jakmile někdo projekt převezme po Vás, může si jít hodit smyčku (bez urážky, nemyslím tím nic špatného směrem k Vám, vidím to prostě tak i z vlastní zkušennosti).
Celé to připomíná přístup javovských programátorů, kde si vezmete jednu konkrétní funkci z jedné konkrétní knihovny a než se dostanete k tomu co a jak to dělá, prolezete mraky dalších knihoven, vrstev a nadstaveb... A to je špatně (bez ohledu na to zda to někdo řeší či ne, a že to někoho určitě bude zajímat, na to vřemte jed ).
Nevím, jak to řeší javovští programátoři. Za sebe mohu řict, že to řeším opačně konstruovanou "podestýlkou". Vždy to co je na vrchu, tak to je vidět, tam se pracuje a nejnovější verze pracuje přímo s tím s čím mám. Každé rozhraní předchozí verze pak na sebe nabaluje emulaci, která se snaží v novém rozhraní emulovat to staré. Mohu to dát někam jinam, protože každá tahle vrstva se už nevyvíjí, ve vlastním programu se nevyskytuje a slouží jen k zachování kompatibility. To jen na obhajobu mého způsobu. Nejde o nadstavby, ale spíš o podestýlku emululujících vrstev. Kromě nafukování binárky a udržování kompatibility nemají význam. U binárně kompatibilních knihoven jsou nutností (nemám rád termín "uzavřené", protože binární neznamená "uzavřené"), u těch ostatních je to na diskuzi.
No, otázka je zda se s tou cenou počítá i do budoucna. Pokud někdo navrhne skříň do níž dám pouze jede hrnek, nebo myslivce, který může mít jen jednoho psa a finito, pak si nejsem tou cenou až tak jist.... Pokud je kód ještě navíc uzavřený, myslím že to může to být v budoucnu velmi drahá záležitost. A určitě sám ze zkušenností víte, že peníze mohou být v takovém případě ještě pořád to nejmenší. Ale - je to asi jen věc pohledu...
Otázkou je, zda na začátku navrhujete skříň, nebo tu skříň z toho uděláte až v průběhu vývoje.
-
Tech: A pokud by se šlo aspoň částečně do mikrojádra (že, plánované kernely 3.x) s delegováním pomocí několika málo serverů, které by nebyl už takový problém udržovat, tak by se problém sajrajtu v jádru na minimum neomezil? Pak si každý vybere jen potřebné moduly-servery a jádro nemusí tahat moc bloated kódu. Navíc se kompatibilita řeší vůči modulu-serveru a ne jádru. On ten polyformismus z OOP má něco do sebe.
Ostatně celé OOP si představte třeba jako vaření (pro dostatečné množství variací). Pak je to spíš otázka jestli tu rýži udělat jako čínu do papírového talířku nebo ji dát k hovězímu v porcelánu.
-
Ondra: Vase odpoved je prave to, co mi neni jasne. Rozumite, mohl bych ve vasi odpovedi nahradit slovo "trida" slovem "funkce", a platilo by to uplne stejne dobre. Takze v cem presne mi ty tridy davaji neco navic, nez funkce? (Jde mi ted o reusability, ja souhlasim s tim, ze tridy jsou obcas - treba v GUI - dobra abstrakce, ale takovych dobrych abstrakci existuji mraky.)
Muzete rict, ze to mate vsechno v jednom baleni. Ale me prijde, ze to v praxi je jen malokdy pravda, ze byste mohl vzit jednu tridu nezavisle na ostatnich, ktera by uz mela vlastnosti, co chcete. Spis budete muset vzit vic trid. Muzete namitnout, ze jich porad bude mene, nez vzit vic funkci a struktur, ale to je dvousecne - zase pokud berete vic trid, zvysujete pravdepodobnost, ze budou obsahovat zatez, kterou nepotrebujete.
Proste, moje pointa je, ze uzitecnost te tridy jakozto abstrakce neni nutne jednotka znovupouzitelnosti. Tedy nevidim, jak to v praxi pomaha znovupouzitelnosti. Ze to neskodi jsem ochoten pripustit (i kdyz mi prakticky prijde, ze tridy jsou jen dalsi misto, kam se daji schovat spagety). Prijde mi, ze to s tou znovupouzitelnosti v OOP si nekdo na zacatku vymyslel jako hypotezu, a pak to po nem vsichni zacali opakovat.
Podle me, vetsina jazyku ma system modulu, a ten resi znovupouzitelnost lepe, nez jestli je jazyk OOP nebo ne. V jednom modulu muzete mit jak vic funkci, tak vic trid, a mate tam presne to, co se tyka dane veci. To jak rozdelite program do modulu nijak neovlivni jeho semantiku, a tim padem je to idealni abstrakce pro znovupouzitelnost (aby ne, proto to tam je).
-
JS: Problém u funkcí budete mít s uložením dat. Funkce nejsou stavové narozdíl od objektů. A pokud si k uložení dat uděláte strukturu a sadu funkcí, které stou strukturou pracují a to celé vystavíte jako "modul", pak už vlastně méte objekt a dalo by se říct, že je to na dobré cestě k OOP.
Pořád si tu někdo myslí, že OOP je nějaký programovací jazyk. Není. OOP je programovací technika a ta se dá realizovat i v ne OOP programovacím jazyku. Jazyky označené za OOP mají jen některé vlastnosti, které výrazně zjednodušují tvorbu objektu (za pomocí tříd).
To ne-OOP řešení se většinou vztahuje ke klasickému řešení, kdy program je napsán na míru nějaké existující relační databázi s pevným formátem... pro příklad. Nemůžete vzít libovolnou funkci, z toho projektu aby fungovala samostatně, nutně narazíte na to, že musíte převzít celý datový model.
U OOP řešení ten datový model je sestaven s objektů stejně jako vlastní program, protože objekty si datové modely tahají sebou (třída definuje jak datový model, tak funkce, které s daty pracují a nikdy jiný s daty pracovat nesmí, proto mohou pracovat samostatně).
Samozřejmě, že některé objekty vyžadují jiné objekty a pokud chcete ty objekty použít, musíte v programu použít i ty, na kterých jsou ty původní objekty závislé. Ale naštěstí nemusíte importovat celý původní projekt. Jako že mám zkušenost s projektem, kde nebyla jiná možnost, přestože jsem z původního projektu použil jen zhruba 5% celkové funkcionality.
-
@o.n.c
Nesouhlasim s tim, ze je treba prebrat u funkci datovy model. Funkce (a tak to bylo odjakziva) se maji koncipovat tak, ze preberou potrebna data v argumentech a neco s nimi udelaji. Vysledek opet predaji v argumentech nebo v nejakem returncod. Takova funkce vubec nevi, ze nejaky datovy model existuje.
Souhlasim s vami, ze OOP neni programovaci jazyk.
OOP (_prostredi_) pouzivam, protoze mi nic jineho nezbyva. Vpodsatte neexistuje GUI , ktera neni v C++ s vyjimnou gtk , ale tam_me_vadi_ty_nazvy_funkci(ktere_gtk_pouziva). Musel jsem se v roce 2001 tedy rozhodnout, ktery z tech frameworku pouziji (qt, fox, wx, fltk). A v tomto prostredi mi vadi ta omezeni, ktera jsou zamerena na to, aby programator neslapl vedle. Uvedu priklad prave z toho roku 2001, kdy jsem stal pred problemem:
Program si nacte nejaky textovy predpis, podle ktereho se maji v dialogu rozmistit na souradnicich x,y elementy (button, label, textfield ...) v nejake velikosti. Programove (pro pozdejsi pristup k temto elementum (objektum) ) musi(muze) tedy existivat nejaky vektor objektu, ktery tyto graficke objekty spravuje.( napr. obj_vektor[]) Kazdy nejaky takovy vyse uvedeny framework ma takovou tridu=Objekt, ze ktere jsou pak ostatni (konkretni butony, labely...) odvozeny. Nejaky konkretni objekt umistim v dialogovem okenku za pomoci metody treba setX(), tedy napr. button umistim button->sexX(20). Co ale nefunguje, je volani metody obj_vektor[5]->setX(20), protoze trida objekt zadnou metodu setX() neimplementuje. Co ted?
-
@o.n.c
Nesouhlasim s tim, ze je treba prebrat u funkci datovy model. Funkce (a tak to bylo odjakziva) se maji koncipovat tak, ze preberou potrebna data v argumentech a neco s nimi udelaji. Vysledek opet predaji v argumentech nebo v nejakem returncod. Takova funkce vubec nevi, ze nejaky datovy model existuje.
Valná většina funkcí bude mít v jednom parametru strukturu představujcící stav nějakého objektu, který ta funkce modifikuje. v OOP jazycich je to this. Podivejte se do svych programů a spočítejte, kolik takových funkcí tam máte.
-
JS: Problém u funkcí budete mít s uložením dat. Funkce nejsou stavové narozdíl od objektů. A pokud si k uložení dat uděláte strukturu a sadu funkcí, které stou strukturou pracují a to celé vystavíte jako "modul", pak už vlastně méte objekt a dalo by se říct, že je to na dobré cestě k OOP.
No, to prave nemam objekt. Muzu si totiz tech struktur v tom modulu udelat vic, a proto je objekt nanejvys specialnim pripadem modulu. Takze, muzu svou otazku polozit znovu - jak mi OOP pomuze, resp. v cem je to vyhodnejsi pro reusability nez klasicke modularni programovani s funkcemi?
Ale asi to nema smysl. Podle me zadny skutecny dukaz pro vase tvrzeni nemate; jinak byste mi uz takovy poskytl.
P.S. A v jazyce s lexikalnimi uzavery mohou funkce byt stavove (nakonec, uzavery lze vyuzit k vytvoreni objektoveho systemu, nicmene uzavery maji mnohem sirsi rozsah pouziti).
-
Já mám neblahé tušení, že nevíte co rozhraní je. Zvlášť po tom, co se ptáte, kterého myslivce máte poslat na lov. To je jako kdyby jste se ptal, u televize, která má dva video vstupy, kompozitní a SCART, kterým vstupem připojíte video?
No a já mám zas dojem, že to nevíte Vy. Vy byste opravdu udělal Televize implements IScart?
K tomu není co dodat, jen, že v okažiku, kdy dostanete televizi se dvěma scarty, tak jste... no víte kde. Schválně: hoďte sem příklad kódu televize implementující rozhraní IScart tak, aby podporovala dva Scarty. A aby šla co nejrychleji a s co nejméně modifikacemi rozšířit o další konektor (ať už SCART nebo s novým rozhraním HDMI). Až to uděláte, dam sem své řešení já (už ho mám v hlavě) a můžeme porovnávat.
U úředníka kontrolujícího psy můžete mít také vlastní rozhraní. Je to rozhraní, kterým komunikuje úředník s myslivcem.
A tomu říkáte reusability? Pro každou blbost vytvořit nové rozhraní? Reusability imho znamená také to, že navrhuji rozhraní tak, aby ho mohli používat pokudmožno všichni. Tzn. když někdo chce vědět, jakého mám psa(y), tak ať už je to veterinář, úředník nebo ras, tak použije to jedno stejné rozhraní.
Rozhraní není objekt, je to komunikační protokol.
Nesouhlasím, ale o tom jsme si psali. Že to je blbina jde ukázat třeba na TCP/IP. Copak je TCP/IP (komunikační protokol po ethernetu) rozhraním ethernetu? Jedním z největších vynálezů v síťování bylo oddělení vrstev s tím, že vyšší vrstva nezáleží na nižší.
S Vaším přístupem by ale nižší vrstva (ethernet) musí znát všechny protokoly, které po něm poběží.
Já tvrdím, že rozhraní je v podstatě popis objektu, říká čím objekt je (Myslivec) popř. co umí. Takže ethernet umí posílat pakety na danou MAC, tak bude mít metodu pošli paket. Jaký komunikační protokol nad tím vystavím je ethernetu naprosto šumák - to neni jeho věc.
A pak jsem pochopil, že Vás trápí název rozhraní. Ale název je jen idenitifikace a nemusí mít
význam...
No, mě trápí to, že rozhraní Myslivec ve skutečnosti nepopisuje myslivce, ale jeho velmi speciální případ. Takže není znovupoužitelný, protože málokdy budu potřebovat takový speciální případ myslivce.
Podtrhuje to i to, že navrhujete, ať ho tedy nepojmenuju myslivec, ale AASDSDSDS. Samozřejmě, v jednom programu bych takový název zkousnul. Ale vy byste takové rozhraní použil v jiném projektu?
Jméno jako takové je pouze identifikátor. Ale jedním z programátorských pravidel je: Co mohu jednoduše popsat tak, že každý dle názvu pozná, o co jde, je správně napsané. A čím jednodušeji to jde popsat, tím je to napsané lépe. (A pokud možno, název objektu/rozhraní by měl shrnovat tento popis do jednoho "multiSlova" popř. "multi_slova" - pak je v podstatě půl dokumentace hotové).
V podstatě to znamená, že čím se mi podaří problém rozložit na jednoduší samostatné entity, tím bývá design programu lepší (samozřejmě s mírou). A ještě významnější důsledek: čím jsou tyto entity obecnější, tím je design programu lepší.
I proto je myslivec je lépe napsaný než myslivec s jedním psem a rozhodně mnohem lépe než myslivec co chodí k úředníkovi, myslivec, co chodí k veterináři atd...
Občas se stane, že během vývoje rozhraní svůj název přestane dokonale vyplňovat.
Pokud se toto stane, pak je IMHO chyba v designu. Pokud mám rozhraní IMyslivecSePsem a najednou potřebuji myslivce s více psy a rozhraní předělám, neodpovídá název. A o čem to svědčí? Že při analýze jsem chybně myslel, že stačí jeden pes.
Dokonce bych řekl, že to bývá jedna z velmi častých chyb při programování - pokud rozhraní A nevyhovuje, protože na daném místě vlastně očekávám B, tak místo abych nadefinoval B a použil ho, ohnu A. Pak o pár dní později zjistím, že jsem ohnul A a tak mi nevyhovuje zas tady, a tak se ho snažím ohnout zpátky - a vznikne paskvil.
Pozor, to je jiný případ než s myslivcem: myslivec s jedním psem i s více psy je furt myslivec, tady nejde o ohnutí, ale opravu. Pokud ale někde chci příjmat smečku a v současné době tam příjmám psa, je velká chyba (byť někdy z důvodu nemožnosti modifikace zbytku kódu nejmenší zlo) ohnout rozhraní Pes. Správné řešení je nadefinovat nové rozhraní Smečka.
-
No a já mám zas dojem, že to nevíte Vy. Vy byste opravdu udělal Televize implements IScart?
Jak to s tím souvisí? Copak televize musí implementovat rozhraní pomocí implements? Jistě může, ale nemusí. Rozhraní přece neříká, jak má být implementováno. Jen předepisuje, co má být implementováno. To "jak" patří do zodpovědnosti toho, kdo to implementuje
K tomu není co dodat, jen, že v okažiku, kdy dostanete televizi se dvěma scarty, tak jste... no víte kde. Schválně: hoďte sem příklad kódu televize implementující rozhraní IScart tak,
aby podporovala dva Scarty. A aby šla co nejrychleji a s co nejméně modifikacemi rozšířit o
I kdyby měla televize implementova deset SCARTů, pořád budete muset nadefinovat rozhraní jednoho SCARTa. Pořád budete potřebovat IScart
další konektor (ať už SCART nebo s novým rozhraním HDMI). Až to uděláte, dam sem své řešení já (už ho mám v hlavě) a můžeme porovnávat.
Hele, tohle jsem už nedávno řešil. Mám model, který má rozhraní, kterým model ovládám a ten model své výstupy posílá na rozhraní, které sleduje jeho view. Mám to rozhraní implementovat jako jedno, nebo jako kontejner? No já vím, že budu jednou potřebovat model prohlížet z vícero než z jednoho pohledu. Ale patří tohle vůbec do zodpovědnosti modelu? Já jsem to vyřešil pomocí distributoru, objekt, který slouží k rozdělení jednoho rozhraní do mnoha rozhraní. Z jedné strany se napojí na model a k druhému se připojují ta view. To je asi odpověď na Vaši otázku. Ano, ta krabice co máte na stole umí 2 SCARTy. Ale já se na televizi mohu podívat jako na objekt, který podporuje jedno rozhraní a to pomocí Implements. A před něj strčím objekt multiplexeru, kterým to budu přepínat a který zvládne těch rozhraní více klasicky funkcí getRozhraní(int index). Mám pak větší volnost. Mohu přímo televizi připojit ke zdroji, bez toho abych tam rval proxy objekty (což přesně dělá Java, kdy implementace jedné metody se deleguje na další metodu, další metodu, další metodu a někde v desáté úrovni je vlastní kód) a nebo prostřednictvím multiplexu vyrobím televizi s vícero rozhraními a celé to pak mohu zabalit do jendoho velkého objektu TelevizeSViceScarty.
Co je asi nejdůležitější, té černé krabičce na druhé straně rozhraní je naprosto šumák, jakým způsobem je to rozhraní implementováno. Jestli tam je televize připojena přímo přes implements, nebo přes proxy objekty, nebo jakkoliv jinak. Třeba tam ani televize být nemusí. Proto pořád tvrdím, že NEVÍTE co to slovo ROZHRANÍ znamená. Roz-hraní. Anglický termín inter-face je výstižnější... mezi-ksicht. Doslova definuje protokol mezi dvěma ksichty. A název toho rozhraní by mělo vystihovat co možná nejpřesnějí smysl protokolu.
A tomu říkáte reusability? Pro každou blbost vytvořit nové rozhraní? Reusability imho znamená také to, že navrhuji rozhraní tak, aby ho mohli používat pokudmožno všichni. Tzn. když někdo chce vědět, jakého mám psa(y), tak ať už je to veterinář, úředník nebo ras, tak použije to jedno stejné rozhraní.
Bohužel, každého bude zajímat něco jiného. Zatímco veterinář se asi bude ptát na jeho zdravotní historii, úředníka bude zajímat třeba úplně něco jiného. Nemůžete při návrhu mýchat deset věcí do jednoho. re-usabilita není v tom, že to namatlám do jednoho zdrojáku a ten použiju všude. re-usabilita je v tom, že si jednotlivé cihly rozeberu a použiju třeba samostatně. Třeba v systému, kde mám jen psy a veterináře nemusím mít myslivce a úředníky. Proč bych měl tedy do takové aplikace tahat třídy nebo rozhraní Myslivec a Úředník.
Rozhraní není objekt, je to komunikační protokol.
Nesouhlasím, ale o tom jsme si psali. Že to je blbina jde ukázat třeba na TCP/IP. Copak je TCP/IP (komunikační protokol po ethernetu) rozhraním ethernetu? Jedním z největších vynálezů v síťování bylo oddělení vrstev s tím, že vyšší vrstva nezáleží na nižší.
S Vaším přístupem by ale nižší vrstva (ethernet) musí znát všechny protokoly, které po něm poběží.
Nevíte co je to rozhraní! Jak jste přišel na to, že nižší vrstva musí znát všechny protokoly nad ním?
Já tvrdím, že rozhraní je v podstatě popis objektu, říká čím objekt je (Myslivec) popř. co
Rozhraní v programovacím jazyce Java nebo C++ definuje, jaké metody můžete nad objektem spouštět s jakými parametry a jaké návratové hodnoty ty metody vrací. Nevidím tam nic o popisu objektu. Nejsou tam stavové proměnné, které objekt maximálně vystihují. Neříkají nic, co ty metody mají ve skutečnosti dělat, což bych si jako popis objektu nejvíc představoval. Když rozhraní IPes má metodu štěkej() neznamená to, že objekt na druhé straně zaštěká. Pokud místo psa vezmu vyhledávacího robota, který při štěkání bude blikat žárovkou, tak zabliká. Pokud bude tenhle pes sloužit k účelu, ke kterému druhá strana rozhraní IPes používá, nevidím na tom nic špatného. Když diskovému ovladači pošlu příkaz na zápis dat, neznamená to, že data se zapíší na disk. Klidně se mohou poslat po síti. Nebo se mohou vypsat na obrazovce. Smyslem rozhraní je to, že jedna strana neví o té druhé nic, ale v jedom má jistotu. To že rozhraní nějakým způsobem implementuje. Rozhraní však neříká jak.
Občas se stane, že během vývoje rozhraní svůj název přestane dokonale vyplňovat.
Pokud se toto stane, pak je IMHO chyba v designu. Pokud mám rozhraní IMyslivecSePsem a najednou potřebuji myslivce s více psy a rozhraní předělám, neodpovídá název. A o čem to svědčí? Že při analýze jsem chybně myslel, že stačí jeden pes.
Nesvědčí to o ničem. Třeba o tom, že z projektu za pár korun, který měl 200 řádek se stala korporátní aplikace s 200 tisíci řádky a to co autor projektu na začátku předpokládál už dávno neplatí. Sám vidíte, že nemohu ani rozhraní předělat. No jasně, je čas pro nové rozhraní!
A o tom jestli dále budete emulovat staré rozhraní musíte rozhodnout podle toho, jaké náklady a přínosy vám emulace nebo neemulace přinese
Pamatujete si na WinAmp 3? To byl mrtvej projekt, protože s vydáním WinAmpa se změnila všechna rozhraní, a nenechala se ta stará. Kde udělali soudruzi chybu?
a) Nepředpokládali při vývoji WinAmp 1, že bude existovat WinAmp 3?
b) Rozšířili stará rozhraní o nové funkce?
c) Nezachovali stará rozhraní v původním návrhu.
Já tvrdím, že c). Vy mě přesvědčujete, že a) je správně
-
Ještě k těm rozhraní a implements.
Mám tady teďka něco jako rozbalený RPC protokol do jednotlivých nodů. Mám tady NumberNode, StringNode, BoolNode, ArrayNode, atd... Všechno to jsou třídy, které uchovávají hodnoty načtené z RPC protokolu nebo to umí zase uložit v tomtéž formátu. No a já jsem se teď rozhodl, že v jednom projektu bych potřeboval všechny tyhle třídy obohatit o tyto metody:
String toString();
String getStringValue();
void setValue(String value);
V zásadě, první metoda převede obsah každého objektu na nějaký řetězec, který se dá vypsat. Druhá metoda převede pouze hodnotu na řetězec, třeba proto, aby se dala vrazit do editačního políčka pro editaci. Třetí metoda vezme řetězec, rozparsuje ho a nastaví objekt do nové hodnoty podle obsahu toho řetězce. Takže pokud u NumberNode tam dám 1, nastaví se do hodnoty 1. U BoolNode tam budu moci poslat "true" nebo "false". Pokud to nepůjde převést, vyhodí to výjimku.
A teď zadání, mám takovou knihovnu plnou takovýhle nodů. Už je někde napsaná, používá se a bude používat na mnoha místech. Jak to udělat, aby každá tato třída měla tyto tři metody.
a) upravím původní rozhraní a obohatím ho o nové funkce?
b) napíšu to jako nové rozhraní.
c) jsem blbej, nepočítal jsem při vývoji software s takovou variantou. Mohlo mě přece napadnout, že jednou budu chtít strukturu upravovat uživatelem
Co je správně? Poraďte mi, ať to vyřeším.
-
Ad IScart: Takže to chápu tak, že to uděláte jako
Televize -<Iskart>- Multiplexor -<Iskart>
-<Iskart>
-<Iskart>
A jak pak třeba uděláte volbu, který kanál na televizi pustit? To bude řešit ten multiplexor? A když budete chtí přidat HDMI, tak předpokládám musíte měnit definici multiplexoru? Nebo pro každé rozhraní bude mít televize vlastní multiplexor - takže budu muset měnit i samotnou televizi?
A před něj strčím objekt multiplexeru, kterým to budu přepínat a který zvládne těch rozhraní více klasicky funkcí getRozhraní(int index). Mám pak větší volnost.
Ne, IMHO máte zaděláno na chybu. Je večer, koukáte se na nejnovější epizodu seriálu přes settopbox. Přijde malej klučina, kterej neví nic o tom, že televize má více scartů (tedy že tam je ještě multiplexor) a vezme scart od videa a zapojí ho do televize do volného konektoru (použije rozhraní IScart od ITelevize). No a co udělá televize? Začne mixovat data z multiplexoru s daty ze scartu. Nebo přepne rovnou na to video. ale to by reálná televize neudělala.
Tím, že implementujete rozhraní IScart jak u televize, tak i u multiplexoru prostě není jasné, co se má kam připojovat - tímto řešením jste vytvořil zbytečný zmatek.
----
Já bych to řešil takto: Mám televizi. Ta má nějaké konektory. Z těch tečou do televize různá data, takže interpretace těch dat je v podstatě záležitost "konektorů" (každej má jiné). No, a když jsem to takhle popsal, tak už je návrh jasný:
ITelevize {
public:
IKonektor getKonektor(typKonektoru, pozice=0)
//metody pro komunikaci s konektorem
void prijmiVideoData(IKonektor, data)
void prijmiAudioData(IKonektor, data)
}
IKonektor {
bool zapocniPrijem() //konektor začne posílat data televizi
}
IHMDIKonektor extends IKonektor
{
void prijmiPaket();
}
IDsubKonektor extends IKonektor
{
void prijmiRGB();
}
IScartKonektor extends IKonektor
{
void prijmiRGB();
void prijmiKompozit();
void prijmiAudio();
}
nevím, jestli to co teče DSubem je totéž, co teče skatem, pokud jo, pak by ještě mělo být rozhraní IRGBKonektor, z kterého by se podědil jak scart, tak RGB.
No a výhody: pro vytvoření televize s jiným rozhraním nemusím vůbec šahat do televize. Pouze vytvořím a implementuji nové rozhraní pro nový konektor (display port). Do televize musím šahat pouze, pokud televize má umět něco více. Pak ale v podstatě to už není ta stará televize, ale např. televize s teletextem, takže v tu chvíli není nic divného na tom, že musím tu televizi upravit (a pravděpodobně podědit nové rozhraní).
Mohu vytvořit televizi s jedním, třemi scarty,sedmi scarty a vždy bude jasné, co kam zapojit a televize se furt bude chovat tak jak má.
A celý tento podle mne čistý návrh plyne z toho, že se na rozhraní koukám nikoli na komunikační protokol: to bych opravdu měl televizi přiřadit rozhraní IScart, protože telvize s ním komunikuje, ale jako na entity. Takže pokud má televize scart konektor, tak prostě telvize musí poskytnout patřičný objekt, nikoli rozhraní. Z toho vyplývá mé chápání rozdílu mezi třídou a rozhraním: rozhraní říká CO, třída říká JAK.
---
Bohužel, každého bude zajímat něco jiného.
Ne vždy. A spousta informací bude společných. On už koncept myslivce je zbytečně speciální - správný koncept je IMHO např. vlastník zvířat. Ten poskytuje metody jako jaká mám zvířata apod. Pokud veterinář chce něco speciálního, tak pak vytvořím pro něj nové rozhraní: protože člověk, co k němu chodí je speciální případ člověka, neboť umí speciální dovednost: podat veterináři informace o zdravotním stavu zvířat. Stejnětak člověk cestující přes hranice např, musí umět dát doklady.
Koncept myslivce v podstatě pak zahrnuje těchto x různých schopností. Máte pravdu v tom, že v jedné aplikaci může být potřeba posílat myslivce k veterináři, v jiném nikoli. V tu chvíli opravdu v každém může být pro "myslivce" (naschvál v uvozovkách, protože každý myslivec vlastně označuje něco jiného) jiné rozhraní. To je ale rozdíl proti tomu, když mám v jednom projektu myslivce s jedním psem a v druhém myslivce s více psy. Myslivec s více psy evidentně zahrnuje i myslivce s jedním psem. Ale nemohu vzít myslivce s jedním psem a přidat mu vlastnictví více psů - protože furt ten myslivec bude mít jednoho "privilegovaného" psa navíc.
Mohu samozřejmě jeho metody přepsat tak, aby toho psa navíc integroval do smečky - jenže to mě ve výsledku zabere více práce, než kdybych vzal myslivce bez psa a implementovat v něm metody vlastnictví psů.
Jak jste přišel na to, že nižší vrstva musí znát všechny protokoly nad ním?
Vy tvrdíte, že rozhraní je komunikační protokol, pomocí které daná entita komunikuje s ostatními objekty. Např. switch v ethernetu příjmá data v protokolu TCP/IP (a posílá je dálú Ergo kladívko, měl by implementovat protokol TCP/IP. To je důsledek vaší definice rozhraní - jako komunikační kanál.
Já tvrdím, že implementovat rozhraní znamená být/mít schopnost. Switch nemá schopnost rozumět protokolu TPC/IP, proto nemá toto rozhraní implementovat.
---
Ad název rozhraní. Doporučil bych Vám připustit, že někdo může mít jiný názor a že jedním slovem (např. rozhraní) může každý označovat trochu jiný pojem. A že pokud ten pojem není pevně přiřazen ke slovu (což v OOP není, jinak by nebyly ty sáhodlouhé debaty, který jazyk je ten jediný správně OOP), že se nedá říci, který význam daného slova je správnější. Takže se prosím smiřte s tím, že chápu pojem rozhraní trochu jinak než vy a místo hádek o termíny se pojďte bavit o tom, který z těch významů je praktičtější a proč.
Co se týče psa a štěkání, tak IMHO slučujete dvě věci. Jedno je schopnost přijmout povel ke štěknutí (k zápisu na disk, k ....). Tomu odpovídá dané rozhraní IStekable s meodou štěkni. Druhá věc je pes ten je zpravidla štěkable, proto by měl implementovat dané rozhraní.
Pak mohu vymyslet koncept psa: řeknu, že pes (rozhraní IPes) je zvíře (extends IZvire), které umí štěkat (extends IStekable). Kodkoli teď může vyrobit (implementovat psa) a může mi ho poslat a já budu vědět, co s ním.
No a pak jsou dvě věci. Někdo umí ovládat psy. Takový člověk by nikdy neřek štěkej robotovy, on to umí se psy. Takže komunikuje s rozhraním IPes. Tento koncept je ale užitečný spíše zřídka. Anebo někdo umí dávat povely ke štěkání: pak umí s rozhraním IŠtěkable a je mu jedno, komu ty povely posílá.... a co protistrana dělá.
Váš pojem rozhraní je pak v podstatě specializace mého: schopnost rozumět konkrétnímu protokolu je vlastnost a jako taková může mít své rozhraní. Až na to, že tím, že si přesněji specifikuji, co je rozhraní, vyloučím špatné návrhy. Např. u televize:
Televize rozumí protokolu scartu? No to přece až tak ne: když scart pustím do HDMI, tak tomu nebude rozumět. Ten kdo rozumí protokolu scartu je pouze ten konektor televize.
A mám s minimem námahy (IMHO hodně dobrý) návrh.
Zatímco ve vašem přístupu televize opravdu komunikuje scartem, takže není nic divného na tom, aby toto rohraní implementovala - v tu chvíli se ale dostáváte do problémů a musíte vymýšlet nějaký multiplexor a stejně to nemusí fungovat - kdokoli může narvat signál do televize přímo.
---
Na zbytek už nebudu reagovat, protože už jsem asi desetkrát psal, že mluvím o tom, jak by se měli aplikace navrhovat od začátku a že pokud je návrh na začátku blbej, tak přepsat ho na dobrej je sice akademicky čisté, ale ne vždy možné či nejlevnější řešení.
-
Na zbytek už nebudu reagovat, protože už jsem asi desetkrát psal, že mluvím o tom, jak by se měli aplikace navrhovat od začátku a že pokud je návrh na začátku blbej, tak přepsat ho na dobrej je sice akademicky čisté, ale ne vždy možné či nejlevnější řešení.
Vida, a zrovna to nejzajímavější jste vynechal. A mě zrovna zajímal váš názor na problém který řeším s tím RPC (NumberNode, StringNode,...) Teda já řešení znám, ale zajímá mne Váš názor.
Protože zatímco všechny příklady tady byly akademické, tak můj poslední příspěvek se opírá o reálnou situaci. Klidně Vám pak dám odkaz do repozitáře, kde najdete řešení, abych dokázal, že nekecám.
-
Na to "nejzajímavější" jsem nereagoval, protože za a) o tom jsem od začátku nic netvrdil (debata začala od čistýho návrhu nějakejch rozhraní do RPG, nikoli o jejich úpravě, toto téma do debaty furt zavlékláte vy), zadruhé je to natolik závislé na tom, jaký je to projekt, kolik lidí a jakým způsobem se podílí na vývoji, jak velk jsou potřeba úpravy a čeho všeho se úpravy dotknou atd...., že nelze říci, kterou metodu bych zvolil. Pro pořádek v kódu je vždy nejlepší mít rozhraní čistá, ale člověk musí často dělat kompromisy.
Jinak to StringNode etc... jsem vynechal proto, protože se na to zaprve vztahuje celý předchozí odstavec, zadruhé jsem se chtěl věnovat tomu, co je IMHO důležité a to mi stačilo demonstrovat na televizi, a za třetí jde o rozšíření funkčnosti, naprosto nezávislé na původním účelu objektů (serializovat/deserializovat do/z řetězce můžu i naprosto cokoli a je mi jedno, jestli to je node nebo islámský terorista) tak není důvod, proč pro to nezavést nové rozhraní (nebo ještě lépe použít již existující rozhraní na serializaci), naopak by byla chyba toto rozhraní vázat na nějaké nody. (Navíc by ta rozhraní i mohla být dvě, protože jedna věc je serializace do strojového zápisu a druhá věc serializace do human-readable, ale to je detail).
S původním tématem to tedy nemá v podstatě společného už vůbec nic.
-
Na to "nejzajímavější" jsem nereagoval, protože za a) o tom jsem od začátku nic netvrdil (debata začala od čistýho návrhu nějakejch rozhraní do RPG, nikoli o jejich úpravě, toto
téma do debaty furt zavlékláte vy), zadruhé je to natolik závislé na tom, jaký je to projekt,
Nevím, kdo mě tu přesvědčoval o tom, že když od začátku píšu skříň, že musím už dopředu počítat s tím, že do ní vložím víc než jeden šálek. Nevím, kdo psal o tom, že v OOP musím při změně rozhraní měnit všechny objekty, které rozhraní používají (načež jsem argumentoval, že vždycky můžeme vytvořit rozhraní nové, namísto změny toho stávajícího). Celá diskuze se točí o udržení čistého kódu po celou dlouhou dobu vývoje software, nikoliv o jednorázovém návrhu. Vy akorát vždycky celou debatu stočíte k tomu, že jde jen o čistotu počátečního návrhu hlavně proto, že byste musel přiznat, že mám celou dobu pravdu. O čemž jsem se přesvědčil právě ve Vaší poslední odpovědi ke které jsem Vás donutil
původním účelu objektů (serializovat/deserializovat do/z řetězce můžu i naprosto cokoli a je mi jedno, jestli to je node nebo islámský terorista) tak není důvod, proč pro to nezavést nové rozhraní (nebo ještě lépe použít již existující rozhraní na serializaci), naopak by byla
Předně tak a o tom to celé je. Mám objektovou strukturu, která už funguje a potřebuju jí nějakým způsobem rozšířit, aniž bych zasáhl do původních rozhraní. Vždycky mohu vytvořit rozhraní nové a nové objekty, které budou dědit původní objekty a nové rozhraní. A funkce nového rozhraní implementovat. Konečně Javovský canvas taky nemá ve svém základním rozhraní funkce pro práci s myší. Musíte to podědit a implementovat rozhraní MouseListener. Zajímavé je také, že MouseListener nemá nic společného s Canvasem, přestože vy jste mě celou dobu přesvědčoval, že IMyslivec, konstruované pro lovecký účel by měl implementovat víc psů,i přesto že jsem k lovu doposud potřeboval jen jednoho. MouseListener přitom slouží k zachytávání akcí myši (IMyslivec slouží k zachytávání informací o revíru během lovu nebo výkonu myslivosti) a nemá sloužit k ničemu jinému (IMyslivec není vhodný k návštěvě veterináře).
Taky jsem psal, abyste se nenechal zmást názvem, protože jistě, mohl jsem to nazvat ne IMyslivec, ale IMyslivecNaHonuListener. Hypotetický autor aplikace pro hony a výkon myslivosti se však domníval, že rozhraní by se mělo jmenovat IMyslivec, protože je pravděpodobné, že na hon budou chodit hlavně myslivci, i když to nevylučuje účast hostů, kteří sice myslivci nejsou, ale pro účel honu mohou IMyslivec implementovat také.
A jinak nedáváte pozor. Knihovna kterou popisuju je přímo serializační nástroj, nejde o to, že ji chci serializovat, naopak mi šlo o analýzu serializovatných dat, nebo o možnost editovat serializovaná data bez nutnosti mít k dispozici původní aplikaci, která data vytvořila. Ale to je vedlejší, nepřečetl jste si ani zadání (byl tam příkaz vypisující obsah nodu pro zobrazení, pro editaci a pro modifikaci), hned mi cpete něco, co jsem vlastně ani nechtel.
-
Nevím, kdo mě tu přesvědčoval o tom, že když od začátku píšu skříň, že musím už dopředu počítat s tím, že do ní vložím víc než jeden šálek.
Vždyť píšete sám, že říkám, že to má být pořádně od začátku, tak proč m prosimvás furt cpete do toho, že chi někde něco nutně a za každou cenu přepisovat??
Právě proto, že je to ve výsledku daleko jednodušší, než se pak snažit nacpat do skříně na jeden šálek víc, je lepší to udělat pořádně hned. Právě proto, že pracovat se skříní jednou jako s jednošálkouvou a jednou jako s vícešálkovou přináší spoustu problémů.
O čemž jsem se přesvědčil právě ve Vaší poslední odpovědi ke které jsem Vás donutil
Nikoli, akorát jste prokázal, že celou dobu mluvíte o něčem jiném. Myslivec vlastnící psy je pořád stejný myslivec, ať už má jednoho nebo více psů, furt je to myslivec. Zbraň na skřety nebo na skřety i draky je furt nutně zbraň i nutně zbraň na skřety.
Ale editovatelný objekt není nutně objekt na serializaci a vice versa, objekt, který umí se vypsat na string není nutně objekt sloužící k serializaci a vice versa. (Vaše zadaní jsem nepochopil, no a? To, jestli slouží metoda tostring k serializaci, nebo k něčemu jinému, na podstatě věci naprosto nic nemění). Proto tyto případy spolu nesouvisí.
Zajímavé je také, že MouseListener nemá nic společného s Canvasem, přestože vy jste mě celou dobu přesvědčoval, že IMyslivec, konstruované pro lovecký účel by měl implementovat víc psů...
Canvas je něco na co se kreslí. Má to nějakou souvislost s myší. Ne. Tak proč by to implementovalo IMouseLisener?
Myslivec je člověk, který se psy a flintou se stará o les. Takže vlastnictví psů je v něm inherentně obsaženo. Proto je Vaše analogie špatná - respektive to analogie není.
Rozhraní IMyslivec popisuje co? Myslivce, který nemůže mít více než jednoho psa. Co to vůbec je? Copak existuje myslivec, který nemůže mít více než jednoho psa? Jestli ano (například to má zakázáno soudně), tak je to naprostá výjimka. Proto je rozhraní IMyslivec navrženo špatně - nepopisuje vlastně nic smysluplného.
Proto také není reusabilní - většina programů, co člověk píše, pracuje s nějakými reálnými objekty (respektive jejich reprezentací). Rozhraní, které reprezentuje nesmysl se do žádného dalšího projektu nebude hodit. A velmi často se ukazuje, že se nebude hodit ani do svého vlastního projektu.
IMyslivec slouží k zachytávání informací o revíru během lovu nebo výkonu myslivosti.... ...Taky jsem psal, abyste se nenechal zmást názvem
To mě jako chcete říkat, že jste říkal myslivec, ale myslel jste kočkodana? Od začátku byla debata o MYSLIVCI, nikoli o nějakém rozhraní, které se náhodou jmenuje IMyslivec. Pokud jste se bavil od začátku o kočkodanovi (nebo o "něčem, co slouží k zachytávání informací o revíru během lovu nebo výkonu myslivosti"), tak jste to měl říci. Ale celou dobu jste používal slovo myslivec, čemuž normální čech rozumí tak, že myslíte myslivce.
Jinými slovy, nezávisí na tom, jak se rozhraní jmenuje, ale co REPREZENTUJE. A pokud rozhraní reprezentuje myslivce, tak protože myslivec může mít více psů, tak má těch více psů mít.
Ono to možná ale přesně ukazuje na jádro pudla: kdybyste při návrhu myslivce místo nad "něčím, co slouží k zachytávání informací o revíru během lovu nebo výkonu myslivosti" myslel nad myslivcem, tak by se nestalo, že by měl jen jednoho psa.
"Reusability": přemýšlím nad objekty takovým způsobem, abych je mohl příště použít.
Celá diskuze se točí o udržení čistého kódu po celou dlouhou dobu vývoje software
:-) Uf. Celou dobu tu diskusi kolem toho točíte Vy. A zřejmě nemůžete pochopit, že diskuse začala o něčem úplně jiném. Já (a jestli jsem pochopil tak i Tiger a tar) se bavíme, jak navrhovat třídy, aby byly co nevíce znovupoužitelné, nikoli o tom, jak ji upravit, když ji někdo navrhnul tak, že znovupoužitelná není. Tam už jde o volbu nejmenšího zla.
O tom jsem již snad desetkrát psal, že v okamžiku, kdy bych musel refaktorizovat již používanou hierarchii, tak že může být jiné řešení výhodnější. Tak to napíšu po jedenácté a snad už Vám to konečně dojde.
---
btw. když už jsme tedy u toho, co udělat, když mám opravit chybu v rozhraní, tak jestli se nepletu, tak ani DirectX (přiznám se, že zrovna DX moc neznám, v jiných knihovnách to tak funguje) nedělá to, že by mělo pro jednu samou věc více rozhraní. Ano, existuje rozhraní ve verzi 7, které je jiné než ve verzi 8. Ale tam se předpokládá, že se bude používat pouze v8 a v7 je čistě pro zachování zpětné kompatibility. Tzn. nejsou to dvě plnohodnotná rozhraní, ale jedno z nich je deprecated, existuje jen proto, aby staré aplikace fungovaly. Rozhodně však není dobrý nápad ta stará rozhraní implementovat v nových aplikacích.
Druhá možnnost (často používaná ve WinApi) je existence dvou rozhraní, jednoduchého a složitého (funkce Něco a NěcoEx). Tady ale nejde ve skutečnosti o shodné rozhraní, jedno poskytuje jiné služby. Kdyby to bylo v objektové hierarchii, tak by to byly pravděpodobně poděděné objekty (NěcoEx od Něco).
-
debata o MYSLIVCI, nikoli o nějakém rozhraní, které se náhodou jmenuje IMyslivec.
Od začátku mluvíme o rozhraní.
Ne tohle je fakt marný :-\
-
Řekněte, zdali je správné toto rozhraní:
interface AASDASDASD
{
color getColor();
};
Pro popis barvy je to dobré rozhraní. Pro popis oběda nikoli. To jasně ukazuje, že kvalitu rozhraní NELZE hodnotit samo o sobě, ale pouze ve vztahu k tomu, co má popsat.
Takže pokud se bavíme od začátku o rozhraní myslivec, tak se bavíme o tom, zdali toto rozhraní dobře popisuje Myslivce. Jinými slovy, nebavíme se o "nějakém anonymním rozhraní IMyslivec", ale o tom, zdali je IMyslivec dobrou implementací Myslivce.
-
Jinými slovy, nebavíme se o "nějakém anonymním rozhraní IMyslivec", ale o tom, zdali je IMyslivec dobrou implementací Myslivce.
Rorzhaní je implementací....??? :o :o :o
OMFG!!!!
-
Jinými slovy, nezávisí na tom, jak se rozhraní jmenuje, ale co REPREZENTUJE. A pokud rozhraní reprezentuje myslivce, tak protože myslivec může mít více psů, tak má těch více psů mít.
Nadobudol som dojem, že rozhranie reprezentuje rolu, resp. sadu schopností, ktoré implementujúca trieda môže nadobudnúť.
V príklade s myslivcom by som teda identifikoval schopnosti, ktoré sú vzhľadom na systém relevantné pre niekoho, kto vie zaujať rolu Myslivca.
Čo dokáže Myslivec? Napríklad: a) Strážiť les (Rumcajs, Řáholec Walker). b) Kŕmiť zver
interface IMyslivec
void straz()
void krmZver()
Potom si môžem navrhnúť tritisíc druhou myslivcov, class MyslivecSJednýmPsom, class MyslivecSKerberosom i OžratýMyslivecSoSedemnástimiPsamiABazukouNaPleci i JavaPoweredRobotPosingAsARanger.
Ja ako klient triedy IMyslivec chcem vedieť len to, že niekto mi postráži les a nakŕmi zver. AKO konkrétne to spraví, je otázka implementujúcej triedy.
-
Ondra: Implementace je významy přetížené slovo - možná jsem ho nezvolil šťastně, v každém případě tím, že rozhraní implementuje, myslím že postihuje, vystihuje, reprezentuje danou věc. Myslím, že kdo se snaží pochopit to pochopí, komu jde jen o to ukázat, že je druhý vůl, se na tom samozřejmě může povozit. Většinou to lidi dělají, když jim dojdou rozumné argumenty.
Alefo: IMHO jsou dva typy rozhraní. Jeden z nich je to co píšeš, až na jeden IMHO ale důležitý detail: vždy tady budou lidi, co umí strážit les, ale neumí krmit a vice versa. Např. lesní stráž či pouze honí pytláky. Proto by mělo být pro každou schopnost vlastní rozhraní, abych nenutil lesní stráž s sebou táhnout pytel žaludů.
Ovšem pak nemám žádné rozhraní pro myslivce. Jak píšeš, myslivec je ten, který umí strážit zvěř a hlídat les. Proto budu mít rozhraní IMyslivec, poděděné z rozhraní IStraziLes a IKrmiZver. Toto rozhraní pak už neříká až tak co daný objekt umí ( když to z něj plyne), jako spíš definuje, co daný objekt je. Protože pokud myslivec je objekt, který umí strážit les a krmit zvěř, tak každý objekt, který implemenentuje toto rozhraní je (z pohledu klienta) nerozlišitelný od myslivce. Ta definice v podstatě říká: "Myslivec je někdo(něco), která umí to, to a to".
Pokud tuto distinkci mezi rozhraním definujícím schopnost a rozhraním definujícím identitu neuděláš, tak se dopustíš té chyby, že uděláš monolitické ropzhraní pro myslivce - a v okamžiku kdy budeš chtít udělat lesní stráž (dejme tomu, že myslivec má pravomoci lesní stráže a navíc krmí zvěř), tak budeš muset zasahovat do třídy myslivec. Pokud to správně rozdělíš předem, tak stačí implementovat rozhraní IHlidaLes a máš lesní stráž.
S tím, že konkrétní implementace je z hlediska rozhraní irelevantní, pak stopro souhlasím.
To, že můžeš navrhnout x druhů myslivců souhlasím - a i klidně třídu s jedním psem. Problém ale začne v okamžiku, kdy ve svém ROZHRANÍ pro myslivce řekneš, že myslivec je i ten, co má psa. Protože to prostě není pravda, nepopysuje to nic smysluplného.
Buďto nepotřebuješ rozhraním postihnout vztah myslivce a jeho psů (pak stačí rozhraní výše), nebo chceš. Myslivec je ale někdo, kdo má PSY!
Takže pokud uděláš rozhraní myslivecsjednimpsem, tak v podstatě uděláš rozhraní pro v realitě neexistující objekt. A takové rozhraní bude v podstatě nepoužitelné v dalších projektech, popř. Ti to bude dělat problém při rozšiřování funkčnosti Tvého projektu...
Když to shrnu: IMHO není vždy chybou, když třída nepostihuje přesně danou entitu. Člověk nemusí psát všechno. Není chybou, když rozhraní nepostihuje celou entitu/schopnost (když je potřeba další vlastnost, jde rozhraní podědit a vlastnost doplnit). Je ale chybou, pokud rozhraní danou entitu/schopnost postihuje špatně. Tzn. je špatně, když rozhraní popisuje vlastně něco jiného, než se s ním člověk snaží popsat. A jedním z exemplárních chyb v návrhu rozhraní je špatná kardinalita vztahů mezi objekty.
PS: Možná by šlo ještě doplnit, že v některých případech se rozdíl mezi rozhraním typu "umím" a rozhraním typu "jsem" stírá, většinou to je v tom případě, kdy danou věc definuje jedna schopnost. Ono také jde říci, že např. umět se seřadit (ISortable) znamená také "být seřaditelným objektem".
A naopak pokud členy mysliveckého sdružení z deinice jsou právě a jen myslivci, tak schopnost říci číslo svého mysliveckého průkazu je inherentní schopnost myslivce a nemá smysl ji vydělovat do samostatného rozhraní. V obou případech je ale třeba dávat pozor, zdali je to oprvadu invariant, nebo zdali např. myslivci neuvažují nad píjmáním svých manželek do organizace.
-
Samozrejme, treba zvazit od pripadu k pripadu, ci schopnosti v interfejsi suvisia spolu uzko a dostatocne charakterizuju dany objekt (ja by som nevahal prirovnat interfejs k sade operacii na sluzbe) alebo ci ide o zjednotenie viacerych schopnosti do jedneho objektu.
S myslivcom, co strazi les a zaroven krmi psy moze byt naozaj problem, ked chceme len strazcu, ktory nevie krmit -- potom sa lahko moze stat, ze trieda implementujuca IMyslivca bude mat v krmeni prazdny kod... alebo bude dokonca hadzat UnsupportedOperationException. Toto sa standardne deje v Java Collections frameworku, kde rozdiel medzi nemennym a premenlivym zoznamom je len v tom, ze nemenny zoznam hadze vynimky v metodach, ktore neimplementuje (co je pomerne nemile).
Ak naozaj predpokladame, ze budu triedy ,,cistych strazcov" a triedy ,,cistych krmicov", tak to treba rozdelit. (Ale toto sa da urobit aj v refactore, vid riesenie s prazdnou metodou).
Len netreba upadnut do extremu, ze preventivne rozdistribuujem schopnosti do jednometodovych interfejsov :-)
Z prispevku vam vypadlo, aky je druhy druh rozhrania. Prvy uplne chapem.
Popravde, nerozumiem celkom, ako suvisi kardinalita s interfejsom. IMyslivec je jedna skatula. Pes je druha skatula. Vztah medzi nimi a jeho kardinalita sa ustanovi v triedach, ktore implementuju IMyslivca, resp. v kontrakte metod. Neviem si predstavit priklad, ako by interfejs mohol zmysluplne vynucovat kardinalitu.
Možná by šlo ještě doplnit, že v některých případech se rozdíl mezi rozhraním typu "umím" a rozhraním typu "jsem" stírá
To je pravda, je to reflektovane v mennej konvencii. ,,Som" sú často reprezentované interfejsmi, ktoré zodpovedajú rolu a sú identifikované prídavným menom. SerialiABLE = serializovateľný. ISortABLE, ComparABLE, teda ,,som trieda, ktorá je serializovateľná / porovnateľná s inou" atď. Často sa stáva, že trieda spĺňa viacero rolových interfejsov.
-
ja by som nevahal prirovnat interfejs k sade operacii na sluzbe)
Poklud je to sada operací k jedné službě, tak to do jednoho rozhraní patří. Např. otevřít "soubor", zapsat, přečíst, zavřít soubor. Tam je to úplně v pořádku - zavření a otevření nemá od operace čtení nebo psaní smysl. I když tady by to asi chtělo rozdělit na IReadable, IWritable a IReadableWritable.
Samozřejmě v reálu člověk z těchto akademických kritérií někdy sleví i v jiném případě (pokud píšu malý jednoúčelový kód, tak nestrávím dva roky návrhem rozhraní). Měl by ale vědět, že: "tady jsem něco zjednodušil". Aby když to v tom zjednodušení začne skřípat (začnu potřebovat lesní stráž), tak hned věděl kde a proč a mohl to opravit - v rané fázi vývoje je většinou takovýto jednoduchý refaktoring (vydělení části služeb z rozhraní A do rozhraní B a podědění A od B) jedodušším řešením, než implementace x metod s výjimkou
UnsupportedOperationException.
Z prispevku vam vypadlo, aky je druhy druh rozhrania. Prvy uplne chapem.
No právě to rozhraní "jsem", oproti rozhraní "umím". Zpravidla rozhraní umím definuje jedmnoduché služby, zatímco rozhraní "jsem" je agreguje do funkčního celku (např. ISortable, IRandomAcces je co umí, ISortableVector pak definuje identitu objektu: být řaditelným seznamem - a je poděděn z ISortable a IRandomAccess).
edit: jasnější příklad.
Jsou to sice subtilní rozdíly, ale pro návrh aplikace je myslím nutné si uvědomit, co které rozhraní reprezentuje. Např. pokud má myslivec psy, tak by někdo mohl propadnout pokušení mu implementovat rozhraní IVector<Pes>. Ale co když pak budu chtít pracovat jen s jeho jezevčíky, nebo jen s jeho oblíbenými psy, nebo..... Těžko budu implementovat rozhraní IVector<Pes>, budu to muset řešit jinak a aplikace bude nekonzistentní.
Pokud si předem řeknu je myslivec seznam psů? "Aha, není"... a místo toho mu udělám metodu getPsy(), tak snadno mu pak dodělám metodu getJezevciky() a getOblibenePsy().
Neviem si predstavit priklad, ako by interfejs mohol zmysluplne vynucovat kardinalitu.
Pokud bude mít myslivec metodu getPes(), vynucuje kardinalitu 1:1 (popř. 1:0). Pokud bude mít metodu getPsy(), tak je kardinalita 1:n.
U myslivce:psa je správná kardinalita 1:n, např. u syna a (biologické) matky je 1:1 - tam by metoda getMatky() byla podivná.... i když to dneska už možná ani neplatí :-) :-).
Pozor, tím neříkám, že implementace myslivce pak nemůže mít pouze jednoho psa. To samozřejmě ano - to je jeho interní záležitost. Rozhraní ale umožňuje mít více psů a tedy pokud kdykoli (v tomto nebo jiném) projektu budu potřebovat více psů, jde o elemenární úpravu.
-
Hlavne mi nie je jasné, ako psy súvisia s interfejsom Myslivca. Podľa mňa veľmi treba zvážiť, či ten coupling tried je naozaj potrebný. Naozaj má každý myslivec psy? Čo ak mám robotického myslivca, ktorý o psoch netuší?
Má každý myslivec (vzhľadom na aktuálne poznatky o systéme) práve jedného psa a je to bezpodmienečne nutné? Ak áno, potom naozaj dodáme metódu IMyslivec#getPes().
Očakávame, že bude mať viac psov? Tak potom IMyslivec#getPsi().
Hoci je otázka, či naozaj medzi sadami služieb, ktoré Myslivec poskytuje, musí byť poskytnutie zoznamu jeho psov.
-----------------------
Ak máme triedu MyslivecSoPsami implements IVector<Pes>, tak niečo je podľa mňa zhnité už na úrovni ,,pravidlá IS-A", čo povedie takmer neodvratne k divnej dedičnosti. MyslivecSoPsami nie určite je vektor psov :-) (A IMyslivec extends IVector je už zhůveřilost.) Tu úplne stačí použiť kompozíciu, kde MyslivecSoPsami implements IMyslivec a má inštančnú premennú List<Psi>.
-
Vau, konečně spřízněná duše :-). I když s Tigerem bych se ati taky shodnul.
Hlavne mi nie je jasné, ako psy súvisia s interfejsom Myslivca. Podľa mňa veľmi treba zvážiť, či ten coupling tried je naozaj potrebný. Naozaj má každý myslivec psy? Čo ak mám robotického myslivca, ktorý o psoch netuší?
Souhlas. To jsem i snad už někde v postech psal, že vlastnit psy může kdokoli a tedy by mělo být spešl rozhraní IVlastníkPsů. Pak je otázka, zdali Myslivec je musí nutně vlastnit, pokud ano (my jsme si ho tak neformálně definovali), pak by měl být od toho rohraní poděděn (v podstatě se tím říká myslivec je člověk, který bla bla bla a taky vlastní psy), pokud ne, tak ne.
Za zmíňku možná tady stojí, že pokud 95%myslivců má psy a často se s nima pracuje, tak považuju za legální říci, myslivec má psy, a robotický myslivec pak bude mít nula psů. Práce s tím (zbytečné definování metody getPsy u robota) bude menší, než neustálé dotazy: implementuje tento myslivec IVlastnikPsu?
Co my schází v objektovvých jazycích je "multitypová kontrola". Např. objekt A implementuje rozhraní IA, IB, IC a ID. Mám funkci, která požaduje objekty implementující IA a IB. Ve všech jazycích s typovou kontrolou, co znám, se to musí vyřešit tak, že nadefinuji rozhraní IAB extends IA, IB a checkuji proti němu.
To má ale velké nevýhody - ten objekt A by tedy měl být poděděn z IAB, IC, ID. To ale tvůrce objektu nemusel vědět. Navíc, další funkce můžče chtít objekt implementující IA a IC. Nebo IB a ID.. Takže v podstatě pro každou použitou kombinaci rozhraní musím psát vlastní rozhraní a to už je trochu opruz. Jak by bylo krásné, kdyby šlo do definice funkce napsat, sem smí objekty, které implementují IA a zároveň IB. Něco jako
fce(IMyslivec + IMaFlintu myslivecSFlintou)
nebo
fce(IMyslivec + IMaPsy myslivecSePsem)
Nejlépe tak, že by šlo definovat
IMyslivec + IMaPsy = IMyslivecSePsy
ale nikoli ve formě dědičnosti, ale opravdu rovnosti. TJ. že každý objekt implementující tyto dvě rozhraní by se považoval za IMyslivceSePsy.
Má každý myslivec (vzhľadom na aktuálne poznatky o systéme) práve jedného psa a je to bezpodmienečne nutné?....
Souhlas.
A IMyslivec extends IVector je už zhůveřilost.
Právě! :-) Jen jsem ukazoval, proč je to zhůvěřilost. Pokud se na rozhraní kouká čistě jako na poskytované služby, jako na něco, čím s polu komunikují dva objekty (v tomto případě myslivec a někdo, kdo chce znát jeho psy), tak by to bylo v pořádku. Proto jsem tvrdil, že tento pohled na rozhraní není správný. Že rozhraní není jen nějaký anonymní popis toho, co daný objekt poskytuje, ale vyjadřuje schopnosti či identitu daného objektu. A jelikož myslivec není seznam psů, tak nemůže implementovat rozhraní ISeznamPsu (respektive IVector<PES>.
Pokud potřebuji vědět, že myslivec je vlastník psů, tak může implementovat rozhraní IVlastnikPsu (to je) a IVectorPsu zahrnout právě jak píšeš nikoli dědičností, ale agregací.
Ono i todle (pod)téma vlastně začalo nad tím, kdy jsem protestoval nad zneužíváním dědičnosti. (na místě, kde by měla být agregace) :-)
-
Co my schází v objektovvých jazycích je "multitypová kontrola". Např. objekt A implementuje rozhraní IA, IB, IC a ID. Mám funkci, která požaduje objekty implementující IA a IB. Ve všech jazycích s typovou kontrolou, co znám, se to musí vyřešit tak, že nadefinuji rozhraní IAB extends IA, IB a checkuji proti němu.
scala> trait A
defined trait A
scala> trait B
defined trait B
scala> class SomethingWithAB[T <: A with B]
defined class SomethingWithAB
scala> class AB extends A with B
defined class AB
scala> new SomethingWithAB[AB]
res8: SomethingWithAB[AB] = SomethingWithAB@f52d950
-
Vau :-) dík za info, řikal jsem si, že takovou hezklou věc určitě už někdo musel vymyslet :-)
-
Pokiaľ ide čisto o kontrolu dátových typov v parametroch, v Jave sa dajú na to hacknúť generiká.
public class Test {
public <T extends Serializable & Comparable<T>> int compareTwoSerializables(T object1, T object2) {
return object1.compareTo(object2);
}
public static void main(String[] args) {
Integer i1 = 2;
Integer i2 = 5;
Test test = new Test();
int result = test.compareTwoSerializables(i1, i2);
System.out.println(result);
}
}
-
jen pro uplnost, jestli to jeste nikdo nezpozoroval. Tato diskuze je ten nejvetsi dukaz, ze OOP je velice problematicka zalezitost a skoro jiste na ho.no.
-
Málo lidí rozumí kvantové teorii a je kolem ní plno sporů. To je ten největší důkaz, že kvantová teorie je problematická záležitost a skoro jistě na ho.no.
-
Málo lidí rozumí kvantové teorii a je kolem ní plno sporů. To je ten největší důkaz, že kvantová teorie je problematická záležitost a skoro jistě na ho.no.
ten primer je spatny a nehodny vaseho nicku. Jen nicotny zlomek lidi, kteri maji co docineni s fyzikou a okolnimi obory se zabyva prakticky s kvantovou fyzikou.
Naproti tomu, kazdy, kdo se jen lehce dotkne profesionalniho programovani je konfrontovan s tézí, ze OOP je ta 'prava' cesta k tomu jak vytvaret spolehlive programy za nizkou cenu.
Kdyz se k diskuzi o OOP sejdou dva diskutujici, tak hned existuji 3 nazory - zrovna tak jako u pravniku. (viz priklad zde s temi psy a myslivci). To neni zadny zaklad pro praktickou cinnost.
-
Ak dáte dvom architektom navrhnúť budovu s rovnakým účelom, budú sa ich návrhy bez diskusie zhodovať?
-
Ad to, že by se správně mělo od začátku navrhovat rozhraní myslivce s více psy. Když uvedu analogii, tak si představte, že událost kliknutí myši se v programu popisuje jako souřadnice X, Y, stav tlačítek a změna kolečka. Nojo, jenomže se objevily multitouch mobily, které zpracovávají víc kliknutí a tažení několika prsty současně --- takže prohlásíme, že všechny knihovny pracující s myší jsou špatně a budeme je preventivně navrhovat tak, aby obsahovaly seznam více současných kliknutí? Pak někdo třeba udělá touchscreen, který je současně čtečka otisků prstů a tak místo seznamu s kliknutími budeme jako "kliknutí" předávat bitmapu všech zmáčknutých bodů?
Ono, navrhováním těch rozhraní preventivně (dopředu myslet na to, že myslivec může mít víc psů) taky program dost zprasíme. Např.:
* místo souřadnice kliknutí myši budeme předávat bitmapu zmáčknutých bodů (touchscreen).
* místo ASCII kódu znaku stisknutého na klávesnici budeme předávat seznam současně stisklých kláves --- a ještě --- co kdyby uživatel měl víc klávesnic --- pro jistotu seznam všech klávesnic a ke každé klávesnici seznam stisklých kláves.
* místo kreslení do jednoho okna budeme pro jistotu paralelně kreslit do N oken, které můžou být ještě navíc na různých displayích, co kdyby uživatel chtěl výsledky programu zobrazovat současně na víc plochách.
* místo otevření socketu na internet budeme předpokládat, že program může přistupovat k N nezávislým internetům připojeným k N síťovým kartám.
... atd --- z toho programu vznikne zpatlanina. Další problém je, že tyto extrémní situace nebudou testovány (málo uživatelů má multitouch, víc klávesnic, víc X-serverů, víc internetů...) a tak se to nepodaří odladit. V programu pak bude spousta zbytečných a zabugovaných abstrakcí, což jeho vývoj zpomalí, nezlepší.
Naopak, myslím, že mít více rozhraní je správně. Je lepší mít rozhraní pro myš, které předává souřadnice, stav tlačítek a kolečko, a pak rozhraní pro touchscreen, které předává seznam všech stisklých bodů. S tím, že když program napsaný pro myš běží na touchscreenu, tak použije rozhraní pro myš a akceptuje jenom jedno kliknutí (a ostatní ignoruje), když program napsaný pro touchscreen je ovládán myší, tak dostane pouze jedno kliknutí (myší nelze kliknout na víc bodů současně), a pouze když program napsaný pro touchscreen běží na touchscreenu, tak může dostat seznam všech míst, kam se kliklo. Podobně --- pokud většina programů reaguje na stisk jedné klávesy, a menšina programů (akční hry) chtějí reagovat na stisk víc kláves, tak je rozumné mít jedno rozhraní pro jednu klávesu a druhé rozhraní pro více kláves, a nenutit všechny programy používat rozhraní pro víc kláves.
-
backup: evidentně se nepohybuješ ve fyzice. I ti, co sefyzikou zabývají, tak mezi sebou vedou dalekosáhlý spory, co vlastně kvantovka znamená,jak její výsledky interpretovat atd... Takže příměr sedí: nikdo neví, co to vlastně znamená, každej tomu rozumí jinak, ale všichni to používaj a dává to dobrý výsledky.
alefo: nikoli, ale architekt je i "umělec" (často bohužel). Myslímale, že i když se návrhy budou lišit, tak budou mít vždy např. vypínače vpodobné výšce, po vstupu do místnosti nejdřív zádveří či předsíň, v obýcákunebude záchod apod.
BLEK.: to je ale jiný případ. Myš je zařízení, které umí přijmout jeden klik. A ty knihovny pracovali s myší. Multitouch device je něco jiného než myš a proto má mít jiné rozhraní. Takže v tomto případě to správně samozřejmě je, ale jde o jiný případ.
Multitouch device může myš "emulovat". Protože "má stejnou schopnost" jako myš: ukázat na jedno místo na obrazovce. Proto multitouch může implementovat i rozhraní myši. To ale přeci neznamená, že multitouch screen je myš.
Rozhraní myši myš popisuje dobře. Že nepopisuje dobře kočkodana (multitouchdevice) je přeci irelevantní. Naopak rozhraní myslivce s jedním psem nepopisujedobře myslivce - myslivec může mít více psů a furt to bude ten samý myslivec.
A ad sprasení: popsání objektu správně přeci neznamená, že následné ho nemůžeme"zjednodušit". Tzn. že by od začátku bylo rozhraní pro multitouch a rozhraní pro myš (které by multitouch devices implementovali také).
Stejně, jako jsou dvě rozraní pro klávesnici, kdy jedním se pracuje jednoduše a s jedním se pracuje (ONKEYUP a ONKEYPRESS události) a pomocí prvního z nich se se seznamem stisknutých kláves dá pracovat. Kdyby bylo takové rozhraní i pro multitouch, třeba by se místo ohromného haló tendle způsob ovládání už dávno používal.... Naopak by byl bonus, že by bylo jasně specifikováno, jak se multitouch gesto interpretuje program psaný pro myš (jestli získá první nebo všechny stisky).
Nebo Ty považuješ za dobré, že v normálnim winapi s multitouch pracovat nelze??
A ad více klávesnic? Kdyby to šlo, myslím, že např. překladatelé do ruštiny byněkdy přivítali, kdyby mohli mít vedle sebe dvě klávesnice, jednu na azbuku ajednu na latinku... A opět to při rozumném designu nemusí znamenat pražádné zesložitění programu.
Já nepopírám, že lze na všechno přijít. Ale na to, že myslivec mná více psů může přijít každý.
-
Souhlasim s BLEKem. Logiku, zapominas, ze ne vzdy jsou to myslivci, kteri navrhuji rozhrani. Nekdy ho predepisuje druha strana. A ta muze predepsat, ze myslivec ma jednoho psa. A s tim nehnes, je to 3rd part library. A co ted?
-
ad k teme:
som zastanca oop tam kam patri.
nebudem pisat erp proceduralnym stylom.
nebudem pisat pisat filter na prikazovej riadke pomocou oop.
co sa tyka jazykov, zastavam nazor, cim viac jazyk zjednodusi pracu programatorovi, tym dalej ho posuva od hw. takze kazdy jazyk ma svoje miesto, nie nadarmo na kazdu ulohu je vhodny nastroj.
os v c#? ano da sa, ale bez stipky assembleru a c?
pisat erp v c? aj to sa da, ale to by som radsej dal vypoved
middleware hru? c# no da sa ale nebude to mainstream (sice mozno na novych mobiloch ano), ale zasa ciste c? da sa, ale bez oop to zasa spomali pracu vyvojarom hier
mam rad jazyky, ktore mi toho vela dovolia... php, javascript, python, c++, ked v tom vie clovek robit tak to vyzera prehladne, jednoducho a funguje to efektivne. ale kedze malo zakazuju, vychovavaju vela zlych programatorov.
nemam rad javu, lebo sa uz len nabaluje. ked som videl lamba v jdk7, som bol sklamany. podobne je na tom java class library, ktoru povazujem za zastaralu.
mam rad c# a .net pre ich schopnost dat nieco rychlo dohromady.
nakoniec, dobry navrh je zaklad vsetkeho, ale zasa raz za cas nie je naskodu refaktoring, pripadne zahodit a zacat znova (vid jpa vs entity beans v jave). kratkodobe naklady zvysi, ale dlhodobe znizi. vsetko ma svoju zivostnost...
-
Logik: "Nebo Ty považuješ za dobré, že v normálnim winapi s multitouch pracovat nelze??"
Ano.
Když Winapi vzniklo, tak existovaly pouze myši se dvěma souřadnicemi a s jedním, dvěma nebo třemi tlačítky. Nikdo nemohl předpokládat, že vznikne kolečko na myši, trojrozměrná myš nebo "myš" s více ukazateli (multitouch).
Takže při navrhování Winapi jsi měl možnosti:
- Udělat tam podporu pro myš, co existuje (myš s dvěma souřadnicemi a nejvýše třemi tlačítky)
- Udělat tam myš s kolečkem a s více stisknutými body, aby to bylo rozšiřitelné do budoucnosti
- Udělat tam supermyš, která má N souřadnic, N ukazatelů a N tlačítek, N koleček a N přepínačů
Bod 2 je neproveditelný (nejseš jasnovidec a nevíš, jaké typy myší v budoucnu vzniknou a jak moc se rozšíří). A když si máš vybrat mezi body 1 a 3, tak je lepší bod 1, protože se to programuje výrazně jednodušeji.
Ono třeba i to kolečko je do toho Winapi dost hnusně dohackované (mám pocit, že se tam posílá zpráva o scrollování, kterou systém předtím nikdy neposílal a mohl ji generovat pouze scrollbar a některé staré programy se s tím neumí vyrovnat a blbnou), jenomže je to furt lepší, než kdyby tam udělali supermyš podle bodu 3.
Dnes jseš třeba v situaci, kdy není technicky problém napsat do Xserveru a GTK multitouch. Problém je, že nevíš, zda se multitouch rozšíří nebo ne. Nevíš, jestli za 10 let budou mít lidi běžně na stole napodobeninu iPadu a budou ho ovládat doteky více prstů nebo ne. Pokud do rozhraní napíšeš multitouch a on se nerozšíří, je to špatně (zkomplikuješ psaní všech aplikací a výsledek bude žádný). Pokud tam nenapíšeš multitouch a on se rozšíří, je to taky špatně (tvůj systém bude zastaralý a těžko ovladatelný). Tak si vyber.
-
@mon_: ...pisat erp v c? aj to sa da, ale to by som radsej dal vypoved ...
to je jen problem vaseho omezeneho rozhledu a nepochopeni, k jakym ucelum byla C vyvinuta. Takze jeste jednou:
Jazyk C se nepouziva na psani aplikaci , ale na psani nastroju pro psani aplikaci.
@mon: ...nebudem pisat erp proceduralnym stylom.
proc? Existuji studie, kolikrat rychleji se napise ERP za pomoci OOP nez proceduralne?
Existuji srovnavaci studie, podle kterych je prokazano, ze OOP ERP je levnejsi, stabilnejsi, vykonejsi ... nez ERP procedural?
-
@backup
ja viem ze c nebolo stvorene na pisanie takychto aplikacii, c bolo stvorene pri tvorbe os, je to stale nizkourovnovy jazyk.
k erp, kazde normalne je postavene nad oop, nemusi to byt zrovna klasicke oop ako tu spominate (java) ale moze to byt ako lotus notes (kde objekty su dokumenty a operacie nad nimi).
neviem si predstavit tu rozsiritelnost a spravovatelnost erp systemov alebo inych informacnych systemov, ktore by nemali objekty.
-
@backup
ja viem ze c nebolo stvorene na pisanie takychto aplikacii, c bolo stvorene pri tvorbe os, je to stale nizkourovnovy jazyk.
Programy pro AVR (jednočipy Atmega) píšu v C++
-
V ERP sa nevyznam, ale ak to zoberieme vseobecne: realita je pripadova studia :-) Keby OP jazyky neboli lacnejsie / efektivnejsie / rychlejsie, nepouzivalo by ich tolko vyvojarov a nebolo by v nich tolko projektov.
Nejde len o paradigmu, ale aj o kombinaciu ,,jazyk + paradigma + nastroje + uciaca krivka + udrzovatelnost".
Ja mam z backupa pocit, ze ma voci OOP strasne predsudky.
-
BLEK.: Samozřejmě, člověk nikdy neví, kam se vývoj vyvine. V tu chvíli je nejlepší popsat správně, to co je. Člověk by to ale měl popsat přesně. Rozhraní myši popisuje myš +- přesně (kdyby tam rovnou udělali podporu více tlačítek, tak by nemusela mít každá myš vlastní ovládací program).
Jinými slovy, když člověk v době vzniku rozhraní vzal kteroukoli myš, šla tím rozhraním popsat. Nadmyš schopná pracovat ve 3D, klikat na více místech najednou apod. je zařízení natolik od myši odlišné, že už se nedá označit jako "myš". Je to prostě něco jiného, byť se tím dá myš emulovat.
To je velkej rozdíl oproti myslivci - mít jednoho nebo více psů nijak nezmění podstatu myslivce a v době vzniku rozhraní myslivec už dávno existovali myslivci, které to rozhraní popisovalo špatně (protože těch více psů nepodchytilo).
PS: Navíc, vždy je možné zjednodušení, jako např. ve WINApi onmousedown/up a onmouseclick. Kdo chce jednoduché rozhraní používá jednoduchej click a když chceš více informací, můžeš použít onmousedown.
Tvoje argumenty se vedou k tomu, že by bylo lepší, kdyby rozhraní ONMOUSEDOWN/ONMOUSEUP neexistovalo. Já tvrdím, že kdyby už v době prvního winapi zavedli rozhraní pro multitouch, bylo by to lepší řešení, než ho zavádět až teď.
Ono to i přesně odpovídá: kdyby to rozhraní bylo, tak by multitouch v pohodě zvládala všechna zařízení, co by to mohla umět (což nezvládají). Naopak situace byla taková, že každý výrobce multitouch tabletu si udělal "svojeho myslivce" - až teprv microsoft přišel s jednotným univerzálním multitouch rozhraním. Bylo by snad lepší, kdyby zůstalo u jednotlivých proprietálních rozhraní?
To co tvrdím je: rozhraní mají být co nejvíce univerzální a mají se navrhovat tak, aby se co nejuniverzálnějšími mohli stát. A rozhraní myslivec s jedním psem to imho nesplňuje.
ondra.novacisko: Ale to je přeci naprosto nesouvisející věc. Ano, člověk se musí umět vypořádat se špatně napsaným rozhraním. To ale neznamená, že nemůže o tom rozhraní prohlásit, že je špatně napsané.
alefo: souhlas, jen bych do součtu doplnil knihovny. Možná je myslíš pod nástrojema, nebo pod jazykem ale myslím, že je to natolik významnej prvek, že si zaslouží vlastní sčítanec.
-
No ale WinAPI vznikalo kedy? 198x? To musí byť dizajnér sakra dobrý vizionár, aby vedel predpovedať veci na 20 rokov dopredu. Multitouch je presne prípad, keď v danej chvíli ani Pýthia kombinovaná so Sibylou nemohol predpokladať, že raz sa bude Windows ovládať viacerými prstami. Rovnako ako nemôžeme predpokladať, že raz budeme systémy ovládať, ja neviem mentálne alebo Nintendo Wii spôsobom.
Môže sa tiež stať, že upadnete do overengineering syndrómu, čo je BLEK.ov veselý príklad so supermyšou.
--------------------
Knižnice sú veľmi a naozaj dobrá pripomienka!
-
ondra.novacisko: Ale to je přeci naprosto nesouvisející věc. Ano, člověk se musí umět vypořádat se špatně napsaným rozhraním. To ale neznamená, že nemůže o tom rozhraní prohlásit, že je špatně napsané.
Ono by možná stačilo se zamyslet nad tím, jak vlastně takové rozhraní vzniká, za jakým účelem. Objekt definovaný pomocí třídy (class) je samozřejmě sám sobě rozhraním a chápu, že myslivec, pokud by měl postihovat všechny své dovednosti by asi měl mít i kontejner psů. Obecně kontejner objektů, které vlastní... protože když bysme to omezily jen na psy, zase se najde nějaký šťoural, který řekne "proč zrovna jen psy?"
Ale rozhraní často vzniká tam, kde jeden objekt chce komunikovat s jiným objektem, aniž by přesně specifikoval, kdo že to má být. Pouze říká, jaké má mít vlastnosti. Rozhraní totiž velice často nedefinuje ten, kdo jej implementuje, ale ten, kdo jej používá a očekává, že jej někdo bude implementovat.
Proto celou dobu tvrdím, že nevíte, co slovo "rozhraní" znamená. Takže pokud mám objekt, který potřebuje komunikovat s něčím, co je zelené, má flintu a psa, a prohlásí to, že je to myslivec, rozhraní máte dané. Stejně tak, pokud objekt potřebuje někoho, kdo umí mlátit kladivem do železa a nazývá to kovářem, tak je rozhraní zase dané. A to i přesto, že rozhraní neřeší třeba kovářovo účetnictví, nebo nákup materiálu.
class IKovar {
public:
virtual void bouchniDoZeleza(Zelezo z) = 0;
}
Jen si to představte v UIčku. Třída Button definuje rozhraní IButtonAction a ta obsahuje jedinou metodu OnPressed(). A toto rozhraní implementuje třeba formulář, který se tak dozví, že uživatel zmačknou tlačítko. Přitom mohu se zeptat: "Je formulář akcí tlačítka". Odpovíte, že ne. Přesto tohle uspořádání má smysl (a neříkám, že to je jediné řešení, ale občas postačuje). A vidíte, rozhraní definuje druhá strana, ne strana, která jej implementuje.
-
Jenže pokud budete přistupovat k rozhraním takto, tak pro každou speciální věc budete muset navrhovat nové rozhraní. Jinými slovy, navržená rozhraní nebudou reusabilní.
V podstatě to, co tvrdím je, že rozhraní je tím více reusabilní, čím více odpovídá tomu, co objekt ve skutečnosti je či jaké má objekt ve skutečnosti schopnosti. (viz to rozdělení dvou typů rozhraní níže).
To ale v podstatě znamená, že dobře navržené rozhraní není jen komunikační protokol, ale vypovídá o vlastnostech samotného objektu.
Problém, na který narážíte s kovářem je ten, že dvě aplikace budou chápat pojem kovář jinak, pro jednoho je to ten, co kupuje železo, pro druhého je to ten, co do něj buší. To jsou ve skutečnosti ale dvě naprosto nesouvisející rozhraní. Tady se opravdu shoduje pouze slovo (identifikátor) a nikoli pojem.
Pokud by ale byly dvě aplikace, které obě potřebují bušiče do železa, tak doufám souhlasíte, že je ideálním stavem, když se podaří navrhnout rozhraní kováře tak, aby obě používali to samé.
----
Když bych to parafrázoval ještě z jiné strany: když si chci s někým porozumět, tak mi nestačí vědět, jaká používá slova, ale co ty jeho slova opravdu znamenají. Tzn. nestačí mi vědět, že mluví anglicky, ale musím znát jeho osobnost.
Pokud rozhraní specifikuje pouze komunikační protokol, tak znám pouze jazyk, takže nevím, jestli to co řeknu urazí, nebo poctí. Když znám i osobnost člověka, se kterým se bavím, tak se mi to nestane. Proto tvrdím, že rozhraní by mělo s sebou nést nikoli jen to, jak daný člověk mluví, ale i kdo je.
-----
Ad IButtonAction je rozhraní, které podle mne zhruba říká: objekt nesoucí toto rozhraní může přijmout pokyn k akci. V tu chvíli mu vyhoví jak tlačítko, tak i formulář. A sem v pohodě :-). Jelikož existuje spousta objektů, které v sobě inherentně obsahují možnost reagovat právě na jednu akci, tak je to rozhraní dobře navrženo. (Narozdíl od myslivce, kdy žádný myslivec v sobě inherentně neobsahuje vlastnost mít právě jednoho psa).
-
Vyrábať dodatočne nové rozhrania nie je až taký problém, ako upravovať existujúce :-)
ondra.novacisko mal pre mňa dobrú poznámku, že pri vytváraní rozhrania sa treba na to dívať z opačnej strany, teda zo strany používateľa (klienta rozhrania). Mnohokrát je to o tom, že ,,potrebujem vec, ktorá" a na základe toho navrhnem rozhranie. Teda v metafore Myslivca: ,,potrebujem vec, ktorá mi postráži les a nakŕmi zver", resp. v inom systéme napr. ,,potrebujem vec, ktorá mi postráži zver, lebo kŕmenie už rieši iná trieda."
Zamyslel som sa, či ,,kým interfejs je" nie je až sekundárne, resp. dôsledok k ,,čo interfejs pre mňa môže urobiť."
Poznámku s dvoma aplikáciami som vôbec nepobral, rovnako ako konštatovania k metafore jazyka človeka. Veď k interfejsu mám dokumentáciu, ktorá jasne definuje zmysel interfejsu a určuje kontrakty pre jeho jednotlivé metódy. Komunikačný protokol tu nechápem ako postupnosť príkazov, ktoré treba vykonať v korektnom poradí, inak nastane problém, ale ako zoznam ponúkaných služieb.
Príklad: java.util.Collections hovorí, že ,,ja som kolekcia, resp. sada objektov", a že poskytuje služby na pridanie, odobratie a ďalších X vecí. (Primárne je charakterizovaná správaním, a až sekundárne objektom z reality, ktorý modeluje.)
To, či komunikujem s kolekciou správne, je záležitosť kontraktu - jasne popísaného v dokumentácii. Ak sa pokúsim vložiť objekt, a nepodarí sa mi to, dostanem po hlave nekontrolovanou výnimkou. Na špecifickom príklade: ak sa pokúsim vložiť do kolekcie null a daná kolekcia to nepodporuje, dostanem NullPointerException. Je to to isté, ako keď vám v tejto chvíli pošlem správu ,,TAK VOLE JAK SE JEDE", tak vás naštvem, lebo som narušil kontrakt (v tomto prípade implicitný, reprezentovaný nepísanou vetou ,,kto ma nazve vulgarizmom, naštve ma.")
-
Ad IButtonAction je rozhraní, které podle mne zhruba říká: objekt nesoucí toto rozhraní může přijmout pokyn k akci. V tu chvíli mu vyhoví jak tlačítko, tak i formulář. A sem v pohodě :-).
Se stejnou logikou tedy, co když formulář bude mít víc tlačítek :-)
Budu tedy muset předělat rozhraní do podoby
IButtonAction::getButton(int index) a následně IButton::onPressed()ve stejném duchu jako
IMyslivec::getPes(int index) a následně IPes::stekej()
Ve vaší úvaze je asi nějaký renonz co? Já vím, namítnete, že to spolu nesouvisí, že myslivec popisuje myslivce a IButtonAction popisuje akci tlačítka. Jenže Myslivec implementuje IMyslivec a MyForm implementuje IButtonAction... kde je tam rozdíl, kromě toho názvu? Já tam žádný nevidím.
Rozdíl tam je. Zatímco IMyslivec navrhujete z pohledu myslivce, IButtonAction se navrhuje z pohledu tlačítka. A právě u toho myslivce se dostáváte do problémů s pochopením. Totiž, to co chcete v praxi nefunguje. Rozhraní se nenavrhují z pohledu toho, kdo je implementuje, ale z pohledu toho, kdo je používá. Vždycky. Už proto, že jedno rozhraní může zpravidla implementovat vícero tříd, zatímco rozhraní často vzniká právě namíru jedné třídě, která jej bude využívat. Cítíte ten vztah? (1:n a 1:1).
Souhlasím s tím, že pokud někde existuje rozhraní, který obsahuje již existující operace vlastnosti, nemusím jej vymýšlet znova, ale použiju již existující. Dokonce, pokud obsahuje část věcí, které potřebuju, mohu jej podědit a rozšířit. Ale zpravidla se nesnažím v rozhraní postihnout všechny možné uživatele toho rozhraní, protože nejsem vizionář a nevím, jaké požadavky budu mít v budoucnu. Mnohem jednodušší a levnější je postihnout v rozhraní jen to, co potřebuje ten jeden uživatel a v budoucnu doufat, že rozhraní maximálně využiji, nebo rozšířím děděním a v případě krajní nutnosti, navrhnu úplně nové. Ani tímto způsobem si neodříznu cestu od uživatelů, kteří používají staré rozhraní a vyhovuje jim to.
-
Logik: "To je velkej rozdíl oproti myslivci - mít jednoho nebo více psů nijak nezmění podstatu myslivce"
Myslivec má jednoho psa - vs N psů je přesná analogie případu "event o kliknutí má jednu souřadnici vs N souřadnic".
Takhle si od stolu můžeš říct, že myslivec má N psů a kdo ho navrhuje s jedním psem je blbej, jenomže ten kód zpracováváním těch N psů několikrát nakyne. Místo myslivec->pes budeš všude psát nějaký iterátor přes všechny psy a for cyklus.
Podobně ti několikrát nakyne kód na zpracovávání eventu od myši, pokud budeš předpokládat, že každý event obsahuje N souřadnic. (třeba otázka - když uživatel klikne současně do víc oken, má se event rozdvojit a doručit více oknům nebo se má doručit do okna kam kliknul dříve nebo do okna, které leží v těžišti těch všech kliknutí, nebo...?)
"a v době vzniku rozhraní myslivec už dávno existovali myslivci, které to rozhraní popisovalo špatně (protože těch více psů nepodchytilo)."
Otázka není jestli myslivec s N psy existuje, ale jak moc je myslivec s N psy rozšířený a jak moc bude rozšířený v budoucnosti. V současnosti třeba existuje 3D myš, ale není rozšířená (lidi jsou líní a nechce se jim ji zvedat), existuje kolečko na myši, které je běžné a existuje multitouch, o kterém nevíš, jak moc se rozšíří. Čili na otázku "bude lepší, když kód na zpracování souřadnic kliknutí myši několikanásobně nakyne kvůli podpoře multitouch?" není jednoznačná odpověď.
-
Žere mi to příspěvky (než to dopíšu, tak mě to odhlásí a příspěvek je v čudu), tak nemám náladu to posiovat, tak krátce.
---
Blek:
právě, že myš je v 99% klasická myš. 3D myš je jiný objekt - slouží k něčemu jinému.
naopak většina myslivců má dva psy a myslivec s jedním psem se v účelu neliší.
(třeba otázka - když uživatel klikne současně do víc oken, má se event rozdvojit a doručit více oknům nebo se má doručit do okna kam kliknul dříve nebo do okna, které leží v těžišti těch všech kliknutí, nebo...?)
No právě, todle je problém právě, když žádné takové rozhraní není. Protože pak každý multitouch implementuje to jednoklikové rozhraní jinak. Takže nějaká konzistentnost UI je v háji.
Naopak, pokud mám rozhraní pro multitouch, tak není problém napsat jednoduchou emulační vrstvu pro onetouch. A ta jednoduchá emulace bude zpracovávat jak pravá onetouch device, tak i např. první klik z multitouch. A aplikace se může rozhodnout, jestli použije složitější rozhraní pro multitouch, nebo jednodušší rozhraní pro onetouch. Bude však všechno konzistentní a předvídatelné. A ani implementátři ovladačů ani kodéři aplikací nebudou muset napsat řádku navíc....
Pro Ondru: Je to ale opět rozdíl mezi onepsem a multipsem: zatímco myslivec zůstává myslivcem, ať už má jednoho nebo více psů, podstata myslivcovství není v tom mít jednoho nebo více psů, Podstata one/mulitouch device je ale v příjmání právě jednoho či více kliků.
Pokud by existovalo něco jako svébytný myslivec s jedním psem, pak by rozhraní pro něho mělo smysl. Nedovedu si ale v praxi představit situaci, kde by opravdu se vyskytoval právě jen myslivec s jedním psem....
---
Ondra:
Rozdíl je ten, že u 99% formulářů (takže zbylé mohu považovat za jinou entitu) je jasné, co znamená odešli se. Naopak polovina myslivců, když je požádám o psa, tak se zeptaj: a kterýho?
--
1) Pokud navrhnu rozhraní reusabilně, pak ten poměr není 1:n
2) Právě proto, že ten poměr je 1:n :-) tak je daleko lepší přizpůsobit clienta (ten co používá) než server (ten co implementuje). Protože u klienta ho musím upravit na jednom místě, zatímco u serveru budu muset upravit vždy každý nový objekt, který rozhraní bude používat.
Když budu mít objekt, který požaduje chrochtající sedminohé zvíře a budou k nim chodit pes, kočka, člověk, prase a roboprase, tak daleko jednodušší je u toho klienta počítat s tím, že přijde ISavec, než u každého zvířete implementovat, jak má kamuflovat sedm nohou a chrochtání.
Navíc tak získám užitečné rozhraní ISavec, které použiji daleko spíš než sedminožku a ještě navíc se v praxi ukazuje, že potřebuji-li obskurní rozhraní, něco jsem blbě navrhnul.
Rozhraní se proto podle mě mají navrhovat nikoli čistě podle potřeb klienta, ale podle předpokládaných serverů. Kdybych ještě přitvrdil, tak řeknu, že servery inherentně nesou kopy "abstraktních" rozhraní, podle toho, kdo jsou (např člověk je humanoid, savec, pojmenovávatelný, okradnutelný.....). Klient si pak pouze "vybírá" rozhraní ze všech dostupných. A má li vybráno, pak to abstraktní rozhraní jen programátor "konkretizuje" zapsáním do kódu. Tzn. ne že programátor rozhraní vytváří, ale akorát popisuje patřičné charakteristiky objektů. Asi jsem platónista.
Např. pořádám hon. Pokud bych použil čistě pragmatické navrhování (dle potřeb klienta), tak řeknu - ok, na honu potřebují pušku a psa. V půlce vývoje ale zjistím, že na vysokou se střílí kulovnicí, zatímco na kachny brokovnicí. A při předání mi řeknou, ale franta má dva psy a vždycky vystřelí z obou hlavní a pro každou kachnu pošle jednoho, to jsme Vám neřekli?
Naopak pokud navrhuji podle serverů, tak si řeknu. Kdo chodí na lovy? No myslivci. A co je důležitého na myslivci ve vztahu k honu: no flinta a pes. Jak je na tom myslivec s flintou a psem? No má jich X. Potřebuji je rozlišovat? No zákazník nic neříkal, tak zatím budu střílet z první flinty a posílat prvního psa....
Hmm, říkal jsem krátce :-( :-)
-
Nedovedu si ale v praxi představit situaci, kde by opravdu se vyskytoval právě jen myslivec s jedním psem....
To je ale přece jedno, jestli je to myslivec, kovář, švestky, myši, lidé, savci. to je přece fuk. Tady je příklad, který začínal tím, že chceme v rozhraní myslivce s jedním psem přidělat víc psů. Nemá smysl se hádat, zda to někdo navrhnul dobře nebo špatně, prostě pořád diskutujete o zadání bez toho, abysme se dobrali nějakého výsledku. Někdo zadal, že myš se může nacházet na jediných souřadnicích naráz. Jaký je rozdíl mezi IMyslivec::getPes() a IMouse::getPos()?
Rozhraní se navrhují tak, aby byla co nejjednoduší. Je blbost do rozhraní dávat věci, které jedna strana neimplementuje a druhá nevyžaduje. Už si vemte, že zbytečné a ještě k tomu vynucené věci musí pak implementovat každý objekt, který se rozhodně implementovat to rozhraní. Přitom i prázdná metoda je špatně, protože netuší, zda druhá strana se může na fungování metody opravdu spolehnout.
A jako argument dám příklad. Klient implementuje rozhraní IMultiTouchMouse, který umí víc pozic naráz. Jenže v době, kdy žádné takové zařízení neexistuje se nakonec omezí na getPositions(1). Rozhraní tedy sice umí mnoho pozic, jenže klient to stejně nevyužije, navíc se nedá takové rozhraní emulovat, v době se takové zařízení objeví. Protože klient se tváří, že sice ho zajímá více pozic, ale využije jen jednu. A tuhle informaci server nezná. Kdyby se klient přihlásil k rozhraní podporující pouze jednopozicovou myš, pak mu server může podstrčit vhodnou emulaci.
Proto je lepší, když existují dvě rozhraní. IMouse a IMultiTouchMouse. Stejně jako IMyslivec (starý) a IMyslivecSVicePsy. Server pak může starým rozhraním poskytnout dostatečnou emulaci, aby uměl spracovat jak staré klienty, tak nové. I noví klienti mohou pak záměrně využít stará rozhraní, pokud jejich potřebám vyhovují, než se zabývat novými. Nemusí totiž vymýšlet tu emulaci. Aplikace počítající s klasickou myší tedy nemusí oslovovat server zkrze IMultiTouchMouse jen proto, že jsem geek a myslím si, že bych měl pracovat s nejnovějšími technologiemi, i když to vlastně aplikace nevyužije. Budu muset složitě zjišťovat, který z předaných bodů je považován za primární pozice. Musel bych znova implementovat tu emulaci. Zatímco v případě, že budu dál používat rozhraní IMouse, emulaci mi zařídí server a ještě k tomu mnohem lépe, než klient, protože má o zařízení víc informací, než poskytuje přes všechna rozhraní, která implementuje.
-
Klient implementuje rozhraní IMultiTouchMouse,
Samozřejmě server, neboli objekt, jehož třída má v Javě "implements" klíčové slovo
-
1) To je dokolečka. diskuse nezačla o tom, jak upravit staré rozhraní, ale o tom, jestli je správný návrh jednoho rozhraní do RPG. Na tématu úpravy jsem pouze demonstroval následný problémy (např. to, že pak mám v systému zbytečně dvě rozhraní a tedy staré objekty nejsou kompatibilní s novými).
2) onetouch a multitouch rozhraní jsou opravdu dvě odlišná rozhraní, neboť v době (a i teď) kdy rozhraní vznikalo, nikdo olutitouch nevěděl. Naopak v době, kdy vzniklo rozhraní IMyslivce, tak většina myslivců už měla více psů. Takže v tomto směru analogie nesedí. Jinými slovy: getPos() pro popis myši dostačuje, getPes() pro popis psa nikoli.
Navíc multitouch/onetouch je klíčová charakteristika ukazovátka, počet psů není klíčová charakteristika myslivce - takže dá se čekat, že multitouch a onetouch se budou užívat jinak, zatímco onepes a multipes se budou používat stejně. Proto multipes a onepes by měli rozhraní sdílet, zatímco multitouch a onetouch nikoli.
3) I tak, kdyby v době vzniku onetouch rozhraní vzniklo multitouch rozhraní, bylo by to lepší. Vzhledem k tomu, že drtivá většina zařízení je onetouch, bylo by nejlepší řešení obě rozhraní, plus ve WINAPI převodní funkce z multi na onetouch. Tím by se zajistila konzistence. V současné době každý multitouch může implementovat onetouch jinak a to vede k zmatení uživatele - jednou to vezme první stisk, jednou všechny..... Navíc každý, kdo implementuje multitouch, tak musí psát sám emulaci onetouch, místo toho, co by byla ve WINAPI napsaná jednou.
4) ". Protože klient se tváří, že sice ho zajímá více pozic, ale využije jen jednu. A tuhle informaci server nezná. "
Právě proto ho nebudu nutit si ji vymýšlet. Pokud klient chce pracovat s jednotlačítkovou myší, proč má touchscreen o sobě lhát, že je jednotlačítkovej?? Něco podobnýho je už u myši teď: když zmáčkneš tlačítko u myši, tak zdali je to pravý nebo levý nerozhoduje přeci myš, ale až nastavení ve WINAPI (jestli je to pro praváky nebo pro leváky).
Stejně tak když zmáčkneš a držíš klávesu, tak proč by měla klávesnice rozhrodovat o tom, jak rychle bude stisk opakovat? Taky o tom nerozhoduje, rozhoduje o tom až winapi a emuluje z "multiklávesy" (ONKEYDOWN/ONKEYUP) "oneklávesu" (ONKEYPRESS). Tak proč by multitouch měl rozhodovat o tom, jak má systém interpretovat stisknutí x bodů naráz. To prostě není jeho práce.
Opět jsme u toho - mulittouch není onetouch. Když se mu někdo snaží onetouch rozhraní vecpat, tak je někde chyba v designu.
-
Jestli je to pořád dokola, tak já ten kruh ukončím: Logiku, prostě se naprosto fatálně mýlíte. Tím myslím, že diskuzi můžeme ukončit :)
-
Opět jsme u toho - mulittouch není onetouch. Když se mu někdo snaží onetouch rozhraní vecpat, tak je někde chyba v designu.
Obrovský omyl!!!! - nikdo se nesnaží onetouch rozhraní nacpat do multitouch objektu. Naopak multitouch objekt často velice rád implementuje i onetouch rozhraní proto, aby se tím zařízením daly ovládat aplikace, které jsou zvyklé na myš. Nebo snad chcete říct všem tvůrcům všech dosavadních aplikací: Vaše aplikace na mém zařízení fungovat nebudou, dokud nepřevedete své aplikace na rozhraní multitouch?
A navíc, multitouch zařízení je schopno implementovat onetouch rozhraní lépe, než aplikace, která je nucena používat multitouch rozhraní i přesto, že by jí stačilo onetouch rozhraní
-
Pokud prohlašujete, že je opravdu lepší, aby každý multitouch po svém (a tedy jinak) implementoval onetouch rozhraní, než aby v systému existovala vrstva, která všechny multitouch rozhraní konzistentně převádí na onetouch (aniž by programátor multitouch musel hnout prstem!), pak se opravdu neshodneme.
Rozdíl mezi námi je v tom, že já jsem řekl několik argumentů, proč je to tak lepší: konzistentnost chování všech multitouch device, možnost centrálního nastavení, menší množství kódu (emulace je napsána jednou a ne x-krát).
Váš argument je pouze "naprosto fatálně se mýlíte" a že mi aplikace pro onetouch nebudou s multitouch fungovat, což ale není pravda (stačí si pořádně přečíst, co píšu, a ne do mých příspěvků projektovat své představy).
-
Pokud prohlašujete, že je opravdu lepší, aby každý multitouch po svém (a tedy jinak) implementoval onetouch rozhraní, než aby v systému existovala vrstva, která všechny
Proč ne? Každé multitouch zařízení může mít jiné parametry detekce prstů. Jistěže může existovat rozhraní emulátoru, kam multitouch posílá svá data a výsledkem je, že emulátor volá onetouch rozhraní a předvá data aplikaci. To může implementovat operační systém. Multitouch zařízení ale má na výběr, jestli to využije nebo ne. A i kdyby multitouch zařízení se vůbec nechtělo s onetouch interface znát, pořád není problém k němu napojit emulátor, který přijímá multitouch eventy a konvertuje to a dál posílá na onetouch rozhraní. Máme tady tedy následující bloky
-onetouch rozhraní, které používají onetouch aplikace
-multitouch rozhraní, které používají multitouch aplikace
-rozhraní emulátoru, který používá multitouch rozhraní a transformuje je na onetouch rozhraní
-objekt vlastního senzoru - multitouch.
Jsou to všechno OBJEKTY. Což je hlavní síla objektového programování. Ovladač senzoru má naprostou svobodu, jak bude své eventy reportovat. Může použít multitouch rozhraní a spolehnout se na to, že operační systém si mezi přijemce připojí emulátor onetouch rozhraní. Nebo emulovat to rozhraní po svém, pokud se domnívá, že standardně dodávaný emulátor nefunguje dobře.
Mimochodem, operační systém Windows u každého zařízení vedou tzv. "Caps", kde každé zařízení hlásí které funkce podporuje aby windowsy věděli, jaká rozhraní k němu mají napojit. Lze to udělat i bez caps, například v C++ se lze pomocí dynamic_cast zeptat multitouch zařízení, zda podporuje onetouch rozhraní. Pokud je mu odpovězeno, že ne, řídící vrstva (operační systém) si vyrobí emulátor, napojí jej na zařízení a onetouch rozhraní implementované emulátorem vystaví všem onetouch aplikacím. Netvrdím, že to mají takhle windowsy udělané, ale já bych tak postupoval při všech změnách nebo rozšíření rozhraní.
A stejně tak, kdybyste mi jako autor myslivce předělal rozhraní IMyslivec na víc psů, já bych byl hrozně naštván, ale vyřešil bych to tak, že bych si ze subversion vytáhl starou verzi a napsal si emulátor (konvertor) na novou verzi a jel bych vesele dál. A vsadím se, že mou úpravu by začlo používat mnoho dalších autorů projektů, kteří pracují s myslivci.
-
Asi podvanácté: debata nezačla o tom, jak upravovat nevhodně napsaná rozhraní, ale jak je navrhovat tak, aby se pokudmožno nemusely upravovat nebo nutnost jejich opravy obcházet napsáním duplicitních rozhraní. S tím, že když bylo původně napsané rozhraní nevhodně, že se s tím někdy nedá dělat nic lepšího než nadefinovat rozhraní nové, souhlasím.
---
Ad multitouch emulace onetouch. Jsou dvě možnosti. Buďto má multitouch inherentně nějaký vlastní způsob, jak zjistit, který klik je preferovaný (např. detekuje ukazováček a bere ho jako primární). V tomto případě by nejčistší řešení bylo, kdyby v rámci multitouch rozhraní dával hint, která souřadnice je ta správná.
V každém případě již ale nejde o čistý multitouch, ten mezi stisky nerozlišuje - takovéto zařízení je schopno přijímat více informací než klasický multitouch. A pokud opravdu vždy v každém okamžiku umí rozhodnout, který stisk je ten preferovaný, pak má zároveň schopnosti rozhraní oentouch a není důvod, proč by ho neimplementoval.
Anebo takový mechanismus nemá a programátor ovladadače by si při implementaci onetouch rozhraní musel vycucat z prstu. Pak má být v systému opravdu onen emulátor, který zachází se všemi true-multitouch zařízeními jednotně, napíše se jen jednou a je konzistentní. V takovém případě je ale IMHO ŠPATNĚ, pokud multitouch zařízení "obejde" systém a svévolně si implementuje onetouch: např. proto, že uživatel bude zmateně hledat, kde se to nastavuje, proto, že v systému bude zbytečně duplicitní kód atd...
Co je ale závěr: v žádném ze scénářů není správně, když zařízení, které má pouze schopnosti multitouch implementuje onetouch přímo. V každé variantě je vždy nějaké lepší řešení. A to je přesně to, co tvrdím: pokud člověk implementuje rozhraní na objekt, který nemá schopnosti tohoto rozhraní, udělal špatně analýzu a dekompozici.
Ad CAPS/RTTI souhlasím - u emulátoru se musí nějak vyřešit, aby ex-multitouch umící z něčeho poznat primární dotek nebylo zbytečně emulováno. To však není ve sporu s mým tvrzení, že onetouch by mělo implementovat pouze to zařízení, které opravdu je schopno samo poznat, který klik je primární.
Ono totiž ve skutečnosti onetouch rozhraní není rozhraní pro zařízení, schopné kliknout na jeden bod. To je rozhraní, pomocí kterého jde z každého kliku uživatele určit primární bod, ať již uživatel klikne na jedno nebo pět míst současně.
Z toho mj. plyne, že multitouch není zobecněním onetouch, jde vlastně o zcela jiné zařízení.
---
Ano: programátor má svobodu. Člověk má taky svobodu. To však neznamená, že všechno, co programátor napíše, je dobré, stejnětak, jako všechno, co člověk udělá je dobré. Tvrzení: ať se bude objekt reportovat okolí jak chce, je správně je ekvivalentní tomu, kdybyste obhajoval anarchii a absenci pravidel.
Mohu to brát jako budhismus: špatný čin člověka mu pokazí karmu a v příštím životě na to doplatí. Špatný čin programátora pokazí kódu karmu a při dalším vývoji na to programátor doplatí :-)
-
Asi podvanácté: debata nezačla o tom, jak upravovat nevhodně napsaná rozhraní, ale jak je -
Já začal diskuzi tím, že někdo argumentoval, že nevýhoda rozhraní je ta, že když se změní, musí se pak změnit všechny objekty, které to rozhraní používají. Což je pravda, ale ne vždy je nutné to řešit změnou rozhraní.
Člověk může trochu předvídat co bude v budoucnu, ale stejně se může stát, že navrhnete rozhraní, které nakonec nevyhoví, protože se to udělá jinak. Nebo vůbec.
takovém případě je ale IMHO ŠPATNĚ, pokud multitouch zařízení "obejde" systém a svévolně si implementuje onetouch: např. proto, že uživatel bude zmateně hledat, kde se to
třeba k tomu je důvod. Nevíte, jen vaříte z vody.
(ad CAPS/RTTI souhlasím - u emulátoru se musí nějak vyřešit, aby ex-multitouch umící z něčeho poznat primární dotek nebylo zbytečně emulováno. To však není ve sporu s mým tvrzení, že onetouch by mělo implementovat pouze to zařízení, které opravdu je schopno samo poznat, který klik je primární).
A kdo to rozhodne?
Mohu to brát jako budhismus: špatný čin člověka mu pokazí karmu a v příštím životě na to doplatí. Špatný čin programátora pokazí kódu karmu a při dalším vývoji na to programátor doplatí :-)
Bohužel tohle vždycky narazí na křivku zvyšujících se nákladů. Zvýšení kvality produktu o jeden stupeň generuje dvojnásobné náklady. V jednom okamžiku jsou náklady tak vysoké, že další zvyšování kvality je ve finále dražší, než všechny náklady, které to ušetří v budoucnu. Tady je třeba ctít ekonomiku. Prostě nelze vyrobit dokonalé rozhraní, protože v konečném důsledku bude jeho používání dražší, než nějaké primitivnější a mnohem levnější řešení.
Koupíte si čínské boty za 300Kč které vydrží jednu zimu, nebo kvalitní boty za 3000kč, které vydrží...? (deset zim?)
-
Programy pro AVR (jednočipy Atmega) píšu v C++
Proboha proc?
-
Programy pro AVR (jednočipy Atmega) píšu v C++
Proboha proc?
Protože je to jednodušší. Potřebuju správce události?
EventManager<32,4> eventMan;
Objekt bude mít frontu událostí o 32 položkách a zvládne 4 časovače. V prostředí, kde má člověk k dispozici 2KB paměti včetně zásobníku si fakt nějaký overhead okolo alokace pamětu (vesměs více neměnné) nemohu dovolit.
Napište mi C alternativu
-
je to c++ ale nie je to oop, na to by si potreboval daku zakladnu spravu pamate implementovat (na op new)
-
A co ta proměnná je, když ne objekt? A proč musí v OOP objekt vznikat dynamicky alokací na haldě? Proč třeba ne na zásobníku?
-
V C by určitě šlo podobného výsledku (ač nevím, co všechno váš EventManager implementuje) dosáhnout pár makry, ale dobrá, jde li pouze o syntaktický cukr, beru to - nějak jsem čekal, že budete používat virtuální metody, dědičnost apod. :-)
-
Já začal diskuzi tím, že někdo argumentoval, že nevýhoda rozhraní je ta, že když se změní, musí se pak změnit všechny objekty, které to rozhraní používají. Což je pravda, ale ne vždy je nutné to řešit změnou rozhraní.
Pokud chci, aby všechny objekty, které používali staré rozhraní, šly použít na místě, kde potřebuji nové rozhraní, tak ať už to vyřeším novým rozhraním, nebo updatem starého, do těch všech objektů prostě šáhnout musím. Srovnávalo se řešení, kdy navrhnu rozhraní od začátku tak, aby vyhovělo úpravám a tomu, kdy nikoli.
Definice nového rozhraní oproti modifikaci starého sice řeší to, že nemusím upravovat jiné klienty, pořád ale musím upravovat všechny servery a navíc mám dvě rozhraní řešící stejnou věc (a jelikož obě používám ke stejné věci, většina objektů bude muset implementovat obě).
třeba k tomu je důvod. Nevíte, jen vaříte z vody.
Pokud je k tomu důvod, pak už dané zařízení není čistě multitouch - protože má důvod prioritizovat nějaký klik. Prostě buď tam ten důvod je, pak to rozhraní ale je onetouch (protože umí určit prioritní klik), nebo ten důvod nemá a pak nemá co implementovat onetouch.
(ad CAPS/RTTI souhlasím - u emulátoru se musí nějak vyřešit, aby ex-multitouch umící z něčeho poznat primární dotek nebylo zbytečně emulováno. To však není ve sporu s mým tvrzení, že onetouch by mělo implementovat pouze to zařízení, které opravdu je schopno samo poznat, který klik je primární).
Co rozhodne? Zdali umí poznat prioritní dotek? No pokud neznám schopnosti zařízení, těžko pro něj mohu navrhovat vyhovující rozhraní. A pokud je znám, tak rozhodují schopnosti toho zařízení.
Bohužel tohle vždycky narazí na křivku zvyšujících se nákladů. Zvýšení kvality produktu o jeden stupeň generuje dvojnásobné náklady. V jednom okamžiku jsou náklady tak vysoké, že další zvyšování kvality je ve finále dražší, než všechny náklady, které to ušetří v budoucnu. Tady je třeba ctít ekonomiku. Prostě nelze vyrobit dokonalé rozhraní, protože v konečném důsledku bude jeho používání dražší, než nějaké primitivnější a mnohem levnější řešení.
Takže již se mnou souhlasíte, že je to řešení lepší, akorát někdy může být neúměrně drahé? To je dobrý posun. :-)
No a ted se stačí zamyslet nad tím, o kolik aplikaci zdraží rozhraní myslivce s více psy oproti jednomu. IMHO marginálně
(pokud budu vždy pracovat např. s prvním psem) a proto je lepší od začátku navrhnout multipsa.
-
Pokud chci, aby všechny objekty, které používali staré rozhraní, šly použít na místě, kde potřebuji nové rozhraní, tak ať už to vyřeším novým rozhraním, nebo updatem starého, do těch všech objektů prostě šáhnout musím.
Nové rozhraní se vytváří většinou proto, aby se nemuselo zasahovat do věcí, které už fungují.
Definice nového rozhraní oproti modifikaci starého sice řeší to, že nemusím upravovat jiné klienty, pořád ale musím upravovat všechny servery a navíc mám dvě rozhraní řešící stejnou věc (a jelikož obě používám ke stejné věci, většina objektů bude muset implementovat obě).
Ono jde o to, co tu změnu iniciovalo. Například to, že jeden jediný klient (objekt, který rozhraní používá) požaduje novou funkcionalitu, kterou servery (objekty, které rozhraní implementují) zkrze staré nemohou implemenetovat. V tom případě s novým rozhraním vzniká zároveň i emulátor, který se snaží "nějak" novou funkcionalitu emulovat zkrze staré rozhraní, nebo nová funkcionalita prostě není k dispozici vůbec (multitouch může zkrze onetouch rozhraní emulovat starou funkcionalitu - onetouch myš). Tady se vám mění jen jeden klient.
Jako příklad uvedu rozhraní, které chci obohatit o funkci toString(). Klient, který chce
objekty tisknout se jich bude ptát, zda existuje rozhraní s funkcí toString(). Pokud existuje,
provede ji, pokud ne, emuluje ji například tak, že to převede na řetězec
"Unknown object:"+typeid(obj).name()
Po změně rozhraní sice bude existovat kvantum objektů, které se nebudou umět vytisknout,
ale časem takových objektů bude ubývat, jak bude zbývat čas tuto funkcionalitu
dodefinovávat. Projekt to ale nezastaví, nikoho to neblokuje, změna tedy nemusí být tak
drahá.
Z výše uvedeného dále vyplývá i výhoda, že nové rozhraní není povinné ve všech projektech. Některé projekty třeba nepotřebují objekty tisknout a tak nové rozhraní ani nebou používat, mohou používat staré objekty bez nového rozhraní. S novým rozhraním totiž
mohu změnu realizovat další úrovní dědění:
class ObjektSeStarymRozhranim: public IStareRozhrani {...};
class INoveRozhrani {...};
class ObjektSNovymRozhranim: public ObjektSeStarymRozhranim, public INoveRozhrani {};
My odkojení C++ dokonce tohle řešíme šablonou
template<class Base>
class ImplementaceNovehoRozhrani: public Base, public INoveRozhrani {...};
Kde Base je pak nějaký objekt, který implementuje IStareRozhrani. Šablona může definovat všechny funkce nového rozhraní, dokonce může zajistit i výchozí implementaci. Speciality se pak řeší specializačí šablony
template<>
void ImplementaceNovehoRozhrano<ObjektSeStarymRozhranim>::novaFunkce() {...};
Nemáte ani pravdu v tom, že servery musí implementovat obě rozhraní, nebo že rozhraní jsou duplicitní. Nové rozhraní většinou implementuje funkcionalitu, kterou straré rozhraní neumí... takže není duplicitní. Server také nemusí nutně implementovat obě. Může také komplet zahodit staré rozhraní, pokud se neplánuje, že nebude fungovat se starými klienty. V tom je opět svoboda, kdy o tom, co bude server implementovat rozhoduje majitel objektu, který rozhraní implementuje a není závislý na ničem jiném.
Takže již se mnou souhlasíte, že je to řešení lepší, akorát někdy může být neúměrně drahé? To je dobrý posun. :-)
Ani náhodou. To jste špatně pochopil. Lepší řešení nemůže být neúměrné drahé. Neuměrně drahé řešení je v konečném důsledku špatné řešení. Možná jen, když zanedbáme ekonomiku celého návrhu, ... jenže to je krátkozraké. Programátor by se neměl utápět ve svých paradigmatech aniž by se ohlížel na ekonomickou stránku celého vývoje. To je pak špatný programátor.
No a ted se stačí zamyslet nad tím, o kolik aplikaci zdraží rozhraní myslivce s více psy oproti jednomu. IMHO marginálně
(pokud budu vždy pracovat např. s prvním psem) a proto je lepší od začátku navrhnout multipsa.
Akademická diskuze
-
V C by určitě šlo podobného výsledku (ač nevím, co všechno váš EventManager implementuje) dosáhnout pár makry, ale dobrá, jde li pouze o syntaktický cukr, beru to - nějak jsem čekal, že budete používat virtuální metody, dědičnost apod. :-)
Dědičnost je taky syntaxtický cukr. Virtuální metody jsou pointry na funkce. To všechno lze na Atmega udělat (i když tedy avr-lib neposkytuje plnohodnotný framework, lze si ho dopsat)
EventManager je pole o N bytů a pole o M longů. N bytů implementuje frontu, M longů implementuje N programovatelných časovačů (čas vypršení). Dalo by se to udělat pomocí struktury a dvou polí, a ano, nakonec makrem. Ale přijde mi to jako zamést bordel pod koberec.
-
Samozřejmě, když se objektu přidává NOVÁ funkcionalita, má mít nové rozhraní. To jsem tvrdil u metody toString, to jsem tvrdil u onetouch/multitouch (porotože IMHO ani jedno z těch rozhraní není nadstavba druhého, jak jsem ukázal v minulém postu). Ale onepes a multipes není implementace různých služeb, jde o tu samou službu.
V původním příkladu nešlo o novou funkčnost - ta si samozřejmě nové rozhraní zaslouží - ale o zpřesnění staré funkčnosti. Neexistuje myslivec, který má jednoho psa a nemá psy - a každý myslivec, který má psy je myslivec, který má psa. Takže každý myslivec se psy bude chtít být použitelný i tam, kde je použitelný myslivec se psem a vice versa. Takže mezi Vašimi příklady a původním není analogie.
Prostě budu-li chtít implementovat myslivce s x psy, tak ať modifikuju staré rozhraní, nebo udělám nové, tak jestli budu chtít pustit multipsa do systému, musím opravit všechna místa, kde klient zpracovává JEDNOHO mysliveckého psa a ve skutečnosti je chtěl zpracovávat VŠECHNY. Pokud to neudělám, tak program nebude korektní (za hranice budou chodit nenaočkovaní psy, budu vybírat málo poplatků za psí známky atd...) Takže se úpravě klientů nevyhnu.
A co se týče dilematu, jestli změnit staré rozhraní, nebo definovat nové, tak v tomto případě je to v podstatě dilema: přinutí mě kompilátor projít všechna místa, kde se pracuje s mysliveckým psem (což stojí hromadu času), nebo mě nepřinutí a já budu muset nějak přijít, na kterých místech je ta oprava nutná, protože se tam má pracovat se všemi psy a ne s jedním. To samozřejmě záleží na situaci, ale první možnost mi zaručí, že v programu nezůstane (logická) chyba. Druhá nikoli. Tím neříkám, že je ta druhá vždy horší, jen ukazuji, že má i nevýhody.
-
Takže se úpravě klientů nevyhnu.
To je právě to, že vy si pořád myslíte, že je častější případ, kdy uživatelů rozhraní je víc, než těch co jej implementují. Jenže to v praxi velmi často bývá naopak. Uživatel rozhraní je většinou právě jeden a objektů, které rozhraní implementují je mnoho. Viz důvody k polymorfismu. Všichni psy štěkají z jednoho místa, ale může tam přijít libovolné množství různých psů.
Jinak, pokud se přidává nová funkcionalita na rozhraní, uživatelé rozhraní se nemusí nikdy nějak extra upravovat. Ano v případě, kdy jde o přechod z jednoho psa na N psů, pak se to dá řešit formou emulace (například vyzvednu prvního psa) a patřičnou funkci označit jako "deprecated", což je krásně vidět třeba v Javě. Viz přechod z funkcí show() a hide() na funkci setVisibility(). Vsadím se, že funkce show() a hide() fungují i dnes, jen je překladač označí patřičným warningem.
V C++ (ve MSVC) se to dělá pomocí declspec(deprecated)
Váš argument s nenaočkovanými psy je divný. Přece pokud úprava na rozhraní vznikla kvůli očkování, je nesmysl, aby veterinář byl nucen používat staré rozhraní. Psa u myslivce, jehož rozhraní podporuje pouze jednoho psa lze taky naočkovat ne?
-
Pokud se rozhraní navrhujou dobře, tak je používá víc klientů. Např. To vaše toString lze využít na různých místech v GUI, při logování, při debugování, při generování komentářů do konfiguračních souborů apod...
jinými slovy, psů je sice mnoho, ale také štěkaj všude, kam přijdou. (chudák zajíc :-)).
Ad nenaočkovaní psy a deprecated: malej problém by byl, kdybych měl myslivce, kterej najednou chce jít přes hranice či k veterináři - a tam je třeba řešit všechny psy. Jenže daleko častěji se spíš stane, že mám myslivce, kterej chodí přes hranice i k veterináři, akorát doteď měl jen jednoho psa.
A najednou za mnou přijde zákazník se slovy: "ale my tam máme myslivce, co má dvě dogy." A takovejdle překvápkům se člověk při vývoji nevyhne.
A v tu chvíli nestačí označit jednu funkci za deprecated (což jinak máte pravdu, že je to jeden z nejrozumnějších konceptů, jak se vyrovnat se změnou rozhraní). Protože musím upravit všechnu funkčnost v klientech, které doteď předpokládali, že jeden myslivcův pes jsou všichni myslivcovi psy.
Jinými slovy. Poku chci najednou posílat myslivce přes hranice, tak je to blíž situaci, kdy implementuju novou funkčnost. Největší problémy jsou ale při změně stávající funkčnosti: (myslivec už dlouho přes hranice chodí, ale teď chce s sebou vzít o psa více...).
-
Logik: "No a ted se stačí zamyslet nad tím, o kolik aplikaci zdraží rozhraní myslivce s více psy oproti jednomu. IMHO marginálně (pokud budu vždy pracovat např. s prvním psem) a proto je lepší od začátku navrhnout multipsa."
To je abstraktní příklad a není jasné, co je tím "myslivcem" a "psem" vlastně myšleno, tak pak nejde na takovou otázku o kolik se vývoj zdraží odpovědět. Když však uvedu konkrétní příklady --- o kolik zdraží navrhovat aplikaci, aby pracovala s více klávesnicemi současně, zobrazovala na více obrazovek současně nebo aby její síťová vrstva přistupovala k více internetům současně, aby místo přístupu na disk používala abstraktní vrstvu pro více datových úložišť --- pak odpověď je --- prodraží to tu aplikaci hodně, kód provádějící danou "zobecněnou" činnost několikanásobně nakyne.
Logik: Vzhledem k tomu, že drtivá většina zařízení je onetouch, bylo by nejlepší řešení obě rozhraní, plus ve WINAPI převodní funkce z multi na onetouch. Tím by se zajistila konzistence. V současné době každý multitouch může implementovat onetouch jinak a to vede k zmatení uživatele - jednou to vezme první stisk, jednou všechny..... Navíc každý, kdo implementuje multitouch, tak musí psát sám emulaci onetouch, místo toho, co by byla ve WINAPI napsaná jednou.
To je příliš kategorické uvažování způsobem "tak to má být". Představme si, že do WINAPI dáme funkce na konverzi všech možných vstupních rozhraní na klávecnici a myš, nejen multitouch, ale třeba i volantu na závodní hry, polohového/akceleračního senzoru, podložky na tancování, EEG snímače (ano, i myšlenkami se počítač dá ovládat a při nějaké terapii se to tak dělá) atd. Pak z toho WINAPI nebude krásné sjednocené rozhraní, ale totální bordel zasypaný spoustou technologií s minimálním podílem na trhu.
A co se týče multitouch, rozšíří se natolik, aby mělo cenu kvůli tomu Windows zesložiťovat a dávat do nich obecnou konverzi? To nikdo neví, proto bych nedělal ani takové kategorické soudy, jakože "multitouch má být sjednocen a když si každý výrobce multitouch napíše emulaci myši po svém, tak je to špatně".
V případě, že se multitouch nerozšíří, pak bude naopak správné, aby každý výrobce multitouch zařízení si napsal emulaci myši po svém a nezesložiťoval tím základní systémové knihovny.
-
o kolik zdraží navrhovat aplikaci, aby pracovala s více klávesnicemi současně...
Ale aplikace ať klidně pracuje s jednou klávesnicí. API OS by mělo být postaveno tak, aby kdyby aplikace chtěla, tak by mohla pracovat s více...
Stejně tak myslivec mže poskytovat více psů a aplikace může pracovat pouze s prvním psem. Náročnost oproti jednopsu je tady minimální.
ale třeba i volantu na závodní hry, polohového/akceleračního senzoru, podložky na tancování, EEG snímač
no z volantu myš snad udělat nejde, podložku na tancování nikdo jako myš používat nebude. Multitouch displej je od začátku zamýšlen jako něco, co má zároveň emulovat myš. To je trochu rozdíl, ne?
Pak z toho WINAPI nebude krásné sjednocené rozhraní, ale totální bordel zasypaný spoustou technologií s minimálním podílem na trhu.
A co jiného je hromada integrovaných driverů dodávaných s windows nebo ještě lépe do linuxového kernelu? To konverzní rozhraní může bejt modul, kterej se doinstaluje v okmažiku, kdy se naisntaluje první multitouch. Proč by z toho měl být bordel nechápu.
A co se týče multitouch, rozšíří se natolik, aby mělo cenu kvůli tomu Windows zesložiťovat a dávat do nich obecnou konverzi?
Nechápu, co je na tom za zesložitění. Jeden "abstraktní ovladač" bez nějakejch závislostech na ostatních komponentách systému.
Na windows v podstatě skoro každá myš, lepší klávesnice atd... si instaluje vlastní ovládací programy, kterejma se víceméně nastavuje to samý, co v stadardním dialogu plus jedna blbina navíc. To se Ti zdá lepší řešení, než kdyby nastavení těch blbin poskytovali jednotně windowsy?
---
Samozřejmě, že někdy se ekonomicky nevyplatí to řešit vše "správně a maximálně obecně" . To ale nic nemění na tom, že všechna zjednodušená řešení mají své chyby a své limity, na které člověk zpravidla později či (z mých zkušeností spíš) dříve narazí.
Zásadní ale je, že k rozhodnutí, jestli to udělám "systémově správně", nebo to zjednodušším mohu udělat až poté, co vím, jak by to mělo být. Pokud budu obě řešení považovat za "rovnocené", tak nemám důvod, proč volit to složitější řešení. Pouze "uvědomění si" problémů jednoduššího řešení mi umožňuje "svobodně" volit mezi nevýhodami (časová náročnost x rozšiřitelnost).
-
Jste zastanci OOP programovani? Zalezi. Je to paradigma, ktere se hodi na reseni urcite, byt pomerne rozsahle, mnoziny problemu. Na neco je vhodne OOP, na neco funcionalni pristup, atp.
OOP je dobre na jistou mnozinu problemu, ale neni to "silver bullet".
http://en.wikipedia.org/wiki/No_Silver_Bullet
Tem kdo necetli, tak doporucuji knihu "The Mythical Man-Month" od autora "Fred Brooks".
-
Logik: Na windows v podstatě skoro každá myš, lepší klávesnice atd... si instaluje vlastní ovládací programy, kterejma se víceméně nastavuje to samý, co v stadardním dialogu plus jedna blbina navíc. To se Ti zdá lepší řešení, než kdyby nastavení těch blbin poskytovali jednotně windowsy?
Ano, je to tak lepší než kdyby každá z těch firem vyrábějících myš/klávesnici přišla za Microsoftem a řekla "hele, my bychom potřebovali do ovládacího panelu přidat tuto položku" a Microsoft jim to tam přidal.
Je lepší, když ten ovládací program napíše každá firma sama, protože: Když ten ovládací program padá, můžeš ho odinstalovat (kdyby bylo ovládání všech možných klávesnic a myší v základním systému, tak to při chybě neodinstaluješ). Když ten ovládací program sežere moc času/peněz na naprogramování a jeho vlastnosti se ukážou jako zbytečné, tak to sežere čas a peníze té firmě co to vyvíjí, ale ne Microsoftu.
BTW. chtěl bys, aby ve standardních Windows byl i ovladač na tohle: http://reidun.files.wordpress.com/2009/05/keyboard-for-blondes2.jpg ? :)
-
BTW. chtěl bys, aby ve standardních Windows byl i ovladač na tohle: http://reidun.files.wordpress.com/2009/05/keyboard-for-blondes2.jpg ? :)
To je pěkný ;D ;D ;D Jestli se dá koupit tak mám pro někoho opožděný dárek k vánocům ;D ;D ;D
EDIT : Tak dá. Stojí zhruba 1300 Kč (49.95$). No je otázka jestli to za tu legraci stojí...
-
BLEK.: To co píšeš je ale čistě ekonomické hledisko. Z hlediska čistoty zdrojového kódu i uživatelské přítulnosti GUI to jednoznačně řešení horší. Čili jak jsem psal: někdy člověk musí slevit z dobrého kódu kvůli ekonomice.
To, že pro microsoft je levnější, když to za něj napíšou jiné firmy je jasné, ale v původním problému, z kterého se diskue vivinula, bych to musel tak jako tak napsat všechno já (nebo nějakej kolega ze stejný firmy).
(kdyby bylo ovládání všech možných klávesnic a myší v základním systému, tak to při chybě neodinstaluješ).
Ty nepoužíváš linux? Tam jsou v jádře ovladače snad na všechno a že by to způsobovalo nestabilitu....
Btw. modulární systém Ti nic neříká? Kdo říká, že to tam musí být napevno?
A ad klávesnice pro blondýny: to je normální klávesnice a ovladač na ní samozřejmě ve windows je. To ale nic nemění na tom, že kromě ceny nemá chybu :-)
-
BLEK.: To co píšeš je ale čistě ekonomické hledisko. Z hlediska čistoty zdrojového kódu i uživatelské přítulnosti GUI to jednoznačně řešení horší. Čili jak jsem psal: někdy člověk musí slevit z dobrého kódu kvůli ekonomice.
Čistota kódu je věc velice subjektivní. Zatímco ekonomické hledisko je věc objektivní. Proto posuzuju čistotu kódu z hlediska ekonomického. Jako měřítko používám čas vyžadující údržbu, nebo znovupoužitelnost kódu. Což může zahrnovat i psaní dokumentace, která může tento potřebný čast výrazně zkrátit. Čistý kód tedy nemusí být superčistý, ideálně podle všech norem a doporučení, ale měl by být dobře zdokumentovaný, minimálně aspoň na úrovni popisu jednotlivých prvků rozhraní. A hlavně jeho údržba či znovupoužitelnost by neměla stát vyrazně víc času. Rozhodně výrazně méně, než čas nutný k reimplementaci na zelené louce
To, že pro microsoft je levnější, když to za něj napíšou jiné firmy je jasné, ale v původním problému, z kterého se diskue vivinula, bych to musel tak jako tak napsat všechno já (nebo nějakej kolega ze stejný firmy).
Nejen, že to je levnější, ale také dává možnost napsat to jinak, nebo lépe. Nehledě na to, že se to psát nemusí víckrát, klidně si ty firmy nebo oddělení mohou šířit jednu knihovnu, kterou používají.
Tohle je otázka, co má obsahovat operační systém? Filesystem? Správu paměti? Správu displaye? Správu jinýho HW. Má obsahovat taky knihovnu pro databázi? Patří to tam? Argument, že stejně většina programů používá MySQL nebo MS SQL, takže by měla být přirozenou součástí OS... cítíte, že je tam něco špatně? Proč proboha ovladač myši by měl mít tu výsadu, že by měl být standardní, pro všechny druhy ovládání?
Každý balíček doinstalovaný do počítače může přinášet nové rozhraní. Kdo tvrdí, že by aplikace musela používat pro vstup myši WinAPI. Když dost výrobců myší začne používat jiné rozhraní, může i naše aplikace používat toto nové rozhraní nezávisle na OS. Konečně, ve Windows existují dvě rozhraní pro myší vstup. Jedno je realizováno přes WinAPI a druhé realizuje DirectInput. To proto, že WinAPI rozhraní neumí některé vlastnosti, jako sledovat akceleraci, nebo relativní pohyb. Valná většina aplikací to totiž nepotřebuje, tak proč by to mělo WinAPI podporovat. A je to také hezký příklad právě na můj argument, že kolikrát je lepší místo přepisování existujícího rozhraní, napsat rozhraní nové. Vždyť vás existence DirectInput nijak neomezuje v používání WinAPI. A ti, kdo rozhraní používají (tedy plní jej daty)? Opět, buď budou data posílat do obou rozhraní, nebo jen do jednoho a nechají systém emulovat to druhé. Jako s tím myslivcem co má jednoho psa a co má víc psů. Myslivec implementuje obě rozhraní, a uživatel rozhraní nechť si vybere, které mu vyhovuje. A nebo myslivec může implementovat jen jedno rozhraní a druhé rozhraní nechat emulovat.
Ty nepoužíváš linux? Tam jsou v jádře ovladače snad na všechno a že by to způsobovalo nestabilitu....
Btw. modulární systém Ti nic neříká? Kdo říká, že to tam musí být napevno?
Tohle jsem chtěl použít jako protiargument. Nestabilitu samozřejmě ovladače způsobují. Viz moje trápení třeba s ovladači ma Wifinu RT2500. Neexistenci jednotného rozhraní v jádře způsobuje, že s každou verzí jádra se musí všechny ovladače přeložit. Pak chápu neochotu výrobců HW dodávat ovladače v linuxu. Jednak musí otevřít zdrojový kód a jednak ho musí neustále udržovat, jak se mění jádro.
Kdyby jádro v linuxu bylo napsáno v C++, pak by byla rozhraní jednoznačně identifikována, přesně definována a jakákoliv změna v rozhraních by se realizovala definicí nového rozhraní a zařízením emulace na staré rozhraní. Staré ovladače by byly binárně kompatibilní a emulace by umonžnila běh starých ovladačů, a přitom by neustálá pomalost emulací dál nutila výrobce používat pro nové ovladače nová rozhraní.
-
Pokud jediné kritérium, podle kterého budete kvalitu měřit, je zisk v době uvedení na trh, tak bude nejlepší naprosto nedokumentovaný kód napsaný jedním vývojářem někde v garáži. Ten se totiž napíše nejrychleji a tedy nejlevněji. Kupodivu takový kód považují všichni za špatný.
Pokud ho chcete posuzovat podle zisků, které přinese v budoucnu, tak pokud nemáte křišťálovou kouli, tak je to úplně stejně vágní kritérium, jako čistota kódu (už proto, že tato kritéria jsou zcela jasně korelované).
Ona ta "výhleová ekonomická výhodnost" kódu je poměrně složené kritérium: zahrnuje čas na napsání, čas na zaučení nového vývojáře pro úpravu kódu, reusabilitu atd... Pokud umíte od pohledu všechna tato kritéria odhalit najednou, asi jste machr. Noirmální člověk zhodnotí jednotlivá částečná kritéria a udělá syntézu. Proto tvrdím, že se bavit o čistotě kódu má smysl (byť jak celou dobu tvrdím, to není jediné a tedy absolutní kritérium).
---
Pokud si jednu knihovnu budou půjčovat různá oddělení, tak o co jiného jde, než definici standardního rozhraní?
A kde tvrdím, že ovladač pro myš by měl být společný pro všechny druhy ovládání? Já tvrdím, že ovladač pro myš by měl být společný pro všechny myši v tom smyslu, že kterákoli myš, když ji zapojím do počítače, má aplikacím vysílatstejné zprávy a chovat se konzistentně.
Ad databáze - ten příměr je mimo z mnoha důvodů. Zaprve různé databáze nejsou různá rozhraní, ale různé implementace. O unifikaci rozhraní různých databází se výrobci evidentně snaží, proč jinak by schvalovali standardy SQL? Další věc je, že databáze není služba, kterou by měl poskytovat OS. Pokud by byla, mělo by být jedno API, jenže to tak prsotě není. Jednotná služba je např. filesystém, přístup ke konfiguraci atd... A tady jde jednoduše ukázat, že filesystémy maj všude jednotné api, i když implementací v linuxu je mraky - a nikdo nenapíše filesystém, který by byl nekompatibilní. Naopak konfigurace ve windows je vcelku jednotná (registry) zatímco v linuxu každý pes jiná ves. Nechci hájit registry, maj dost much, ale samotná myšlenka jednotného ukládání konfigurace linuxu velmi schází.
---
Ad linux: ale přeci to, že jsou v linuxu ovladače se považuje za velké plus linuxu. Strčím placku a funguje to.
Problém linuxu není v tom, že má v sobě ovbladače. Problém linuxu je v jeho naprosto nemodulárním jádře, které se musí kvůli každé blbině překompilovat.
Problém linuxu není v tom, že není v C++. Takto by to šlo napsat i v C (byť o něco pracněji). Problém je v tom, že kdyby tam bylo x verzí rozhraní pro každou blbost, tak by jádro místo jednoho volání vždy muselo dělat x emulací a výkon by šel do kopru. Zrovna v linuxovíém jádře je to, že stará rozhraní nenechají dožít, ale odstraňují je pokud možno hned, pochopitelné.
-
A todle si nechám na samostatnej post, protože je to důležitý :-)
Obrovskej rozdíl mezi WINAPI + DirectInput kontra onepes a multies je v tom, KDO POŽADUJE ZJEDNODUŠENÍ.
U myši 99% aplikací chce pouze vědět, kam se kliklo. Proto se udělalo jednodušší rozhraní pro myš. Původcem zjednodušení je tedy typický klient.
Naopak u jedno a multipsa není původcem zjednodušení klient, ale server! Většina klientů myslivce (ať na honu, kde přeci nebude mít myslivec u nohou tři psy a furt posílat jen jednoho, tak u veterináře, který očkuje všechny psy, nebo na hranicích atd....) chce pracovat se všemi psy myslivce. Akorát aktuální implementace myslivce počítá jen s jedním psem. Takže zjednodušení rozhraní tady vychází nikoli z potřeb klientů rozhraní, ale od serveru. A to je myslím klíčový problém.
Pokud zjednodušuji na žádost klientů, tak server umí poskytovat i komplexní služby, není tedy problém mít od začátku dvě rozhraní (jednodušší a komplexní), popř. v horším případě to komplexní dopsat. Nemohu se přitom dopustit chyby, kompilátor vychytá, u kterých všech objektů je nové rozhraní potřeba doimplementovat.
Pokud ale zjednodušuji kvůli serveru, tak v okamžiku, kdy chci vytvořit plnohodnotný server, musím opravit všechny klioše, používající zjednodušené rozhraní. Ale TADY MI NIKDO NEPOVÍ, kteří to všechny jsou. S velkou pravděpodobností se dopustím chyby.
PS: A klientů je velmi často hodně: např. krásně to jde ukázat na myši. Čeho je více? Typů myší, nebo aplikací myš používajících? Nebo čeho je více? Typů soubor (soubor, socket, nějaký bitový device apod.), nebo aplikací starajících se o soubory? Existuje více databází, nebo více uživatelů databází.
PPS: Navíc ten příklad jen podporuje mojí teorii, protože se věci poněkud změnili :-).
DirectInput je deprecated, místo něho se má pro myš použít RAW Input, komunikující standardně pomocí windowsích zpráv. Z pohledu WINAPI jde v podstatě o rozšíření původního rozhraní o jednu zprávu - metodu.
Proč tedy microsoft ustoupil od definování nového rozhraní a místo toho rozšířil staré rozhraní, když je to tak špatně???
Nebo jsi možná myslel DirectInput rozhraní pro herní ovladače? I to je deprecated a místo toho je XInput. A kupodivu to je nedoporučené používat pro myši a podobné zařízení. Proč? No protože myš není herní ovladač. Opět to potvrzuje to, co jsem tvrdil. Pro věci stejné povahy má být jedno rozhraní, a naopak věci různé povahy implementovat stejné rozhraní nemají.
-
A todle si nechám na samostatnej post, protože je to důležitý :-)
Obrovskej rozdíl mezi WINAPI + DirectInput kontra onepes a multies je v tom, KDO POŽADUJE ZJEDNODUŠENÍ.
U myši 99% aplikací chce pouze vědět, kam se kliklo. Proto se udělalo jednodušší rozhraní pro myš. Původcem zjednodušení je tedy typický klient.
Naopak u jedno a multipsa není původcem zjednodušení klient, ale server! Většina klientů myslivce (ať na honu, kde přeci nebude mít myslivec u nohou tři psy a furt posílat jen jednoho, tak u veterináře, který očkuje všechny psy, nebo na hranicích atd....) chce pracovat se všemi psy myslivce. Akorát aktuální implementace myslivce počítá jen s jedním psem. Takže zjednodušení rozhraní tady vychází nikoli z potřeb klientů rozhraní, ale od serveru. A to je myslím klíčový problém.
Jediný klíčový problém je ten, že to byl špatný příklad. Měl ilustrovat řešení v situaci, kdy je třeba změnit rozhraní z jednoho psa na multipsa. Vy jste se pustil do kritiky programátora, který navrhl onepsa.
A neuvažujete ani o tom, že programátor se rozhodl třeba na základě krátkodobého ekonomického výhledu, protože předpokládal nějaký ekonomický zisk (ekonomický zisk mohl být třeba i časový zisk, měl to prostě rychleji napsané). Že následně jeho odhad byl velice pohodnocený (knihovnu myslivce může použít v dalších projektech bez větší námahy, ušetří mu to spoustu času), to už je jiná věc. Pořád by se ale vyplatilo navrhnout další rozhraní, než vynaložit obrovské (časové) náklady na přepis všech míst, kde se původní rozhraní používá.
Konečně, sám jsem si to nedávno vyzkoušel po tom, co jsem v rozhraní obecného pole přejmenoval funkci size() na funkci length(). Uvést produkt do kompilovatelného stavu mi trvalo víkend a ani teď nemohu říct, že je to všude opravené. Mám projekty, které rozhodně nebude možné přeložit, ale ještě jsem se k nim nedostal.
-
Naopak u jedno a multipsa není původcem zjednodušení klient, ale server! Většina klientů myslivce (ať na honu, kde přeci nebude mít myslivec u nohou tři psy a furt posílat jen jednoho, tak u veterináře, který očkuje všechny psy, nebo na hranicích atd....) chce pracovat se všemi psy myslivce. Akorát aktuální implementace myslivce počítá jen s jedním psem. Takže zjednodušení rozhraní tady vychází nikoli z potřeb klientů rozhraní, ale od serveru. A to je myslím klíčový problém.
To je nějaký renons ne? Nějaká ujetá úvaha. Serverem nazývám ten kdo má implements, zatímco klientem ten kdo volá metody. Jak jste došel k závěru, že původcem je server (tedy ten kdo implements). Kdo vyžaduje víc psů? Ten kdo to implementuje? Tomu je to jedno, ten musí implementovat tolik rozhraní, kolik potřebuje, aby mohl v systému existovat. Klienti, tedy kusy programu, které volají metody rozhraní typicky od těch metod něco očekávají. Pokud vznikne potřeba mít rozhraní s větším množstvím psů, pak ta potřeba vychází od klientů, ne od serveru!
Zapomeňte už konečně na koncepsi "IS-A". To je pomůcka pro začátečníky, když se učí poprvé dědit. Do OOP ale nepatří. Praxe vás asi ještě nenaučila, že "implements" není dědění, takže implementovat rozhraní myslivce s jedním psem a zároveň rozhraní s vícero psy nelze číst jako že myslivec má jednoho i víc psů dohromady. Nejde to prostě tady aplikovat.
-
BLEK.: To co píšeš je ale čistě ekonomické hledisko. Z hlediska čistoty zdrojového kódu i uživatelské přítulnosti GUI to jednoznačně řešení horší. Čili jak jsem psal: někdy člověk musí slevit z dobrého kódu kvůli ekonomice.
Z hlediska uživatelské přítulnosti GUI je nejhorší, když se sleze spousta návrhářů a začne říkat "já bych do toho dialogu ještě přidal to...", "a já bych tam ještě přidal tamto...", "a já jsem ještě dostal tento nápad, to tam musíme dát...". Pak máš v GUI spoustu nekonzistentních myšlenek a uživatel se v tom nevyzná.
Když máš víc programů na ovládání, sice odlišných, ale každý se svou vlastní vnitřní konzistencí, je to pro uživatele lepší. Prostě si vybere jeden, který má funkce co potřebuje, a ten se naučí a používá.
To, že pro microsoft je levnější, když to za něj napíšou jiné firmy je jasné, ale v původním problému, z kterého se diskue vivinula, bych to musel tak jako tak napsat všechno já (nebo nějakej kolega ze stejný firmy).
Nejde jen o to, že je to levnější. Jde o to, že ty (ani Bill Gates, ani Steve Ballmer...) nemůžeš z pozice autority určit, který způsob nastavování myši a klávesnice je pro uživatele nejlepší. Prostě to nevíš. Když ti někdo řekne "já mám tento nápad, to uživatelům pomůže", tak nejseš schopen určit, zda je to blbost nebo geniální myšlenka. Proto je nejlepší dát uživatelům svobodu vybrat si ovládání jaké chtějí a nevnucovat jim je autoritativně.
(kdyby bylo ovládání všech možných klávesnic a myší v základním systému, tak to při chybě neodinstaluješ).
Ty nepoužíváš linux? Tam jsou v jádře ovladače snad na všechno a že by to způsobovalo nestabilitu....
Používám Linux a nestabilitu to způsobuje - OpenSuse mi kdysi spadlo hned po instalaci kvůli ovladači grafické karty. A na starém notebooku mi po upgradu kernelu nefunguje něco s pravděpodobností 1/4. (z 12 kernelů od Linuse byly tři rozbité - APM, swapování na FAT a PCMCIA).
Myslím, že ty sjednocené ovladače jsou jedna z nejhorších chyb Linuxu, která přispěla k jeho nepoužitelnosti na desktopu. Příklad: předevčírem jsi nainstaloval ovladač do Widlí, včera ti to spadlo. I BFU bez jakékoli technické znalosti je schopno určit, že to asi spadlo kvůli tomu ovladači, dokáže vlézt do nouzového režimu, ovladač odinstalovat, a může zkusit jinou verzi ovladače nebo jiné zařízení. Naproti tomu na Linuxu, nainstaluješ celý systém naráz se všemi ovladači, PRÁSK! spadne to, nemáš sebemenší potuchy proč (leda, že bys měl sériovou konzoli a uměl dekódovat stacktrace což BFU nemá a neumí).
Btw. modulární systém Ti nic neříká? Kdo říká, že to tam musí být napevno?
Když dopředu nevíš, jaká všechna nastavení klávesnice/myši budou potřeba, tak je těžko to navrhovat modulárně. To je pak opravdu nejlepší říct, že "modul" je "sys" soubor, který vybírá zprávy odněkud a posílá je někam a "exe" soubor, který mu nastavuje parametry.
A ad klávesnice pro blondýny: to je normální klávesnice a ovladač na ní samozřejmě ve windows je. To ale nic nemění na tom, že kromě ceny nemá chybu :-)
K té klávesnici pro blondýny dodávají speciální ovladač na aktivaci těch klávesových zkratek a možná ještě něco. Nemusíš ho instalovat, a pak se to chová jako obyčejná USB klávesnice.
-
K původní otázce:
Ano - většinou.
Důvody jsou syntaktický cukr, typová kontrola, zapouzdření, dekompozice.
První dva důvody jsou jasné. Snad jen k té typové kontrole. Interface (v jazycích jako je Java) jsou hodně šikovné. A používám je právě pro rozšíření typové kontroly. Prostě svážu, co kam smí.
Zapouzdření netuším, jak může být řešeno v procedurálního programování. Ve funkcionálním se možná dají použít uzávěry, ale tomu nerozumím tak dobře.
Hodně mi vyhovuje dekompozice problému na malé logické celky, které si pečlivě navrhnu, rozdělím úlohy, a otestuju. Pak komponuju jednotlivé vztahy objektů, a ty objekty, které jsou špatné, tak přepisuju, nebo vyhodím. Domnívám se, že pokud se problém takto nerozdělí, nelze OOP dobře používat a jen se bastlí. Někde jsem četl, že když má třída více, jak dejme tomu deset metod, je moc velká. Postupem času s tímto tvrzením začínám souhlasit.
OOP považuji za metodiku. Podle mne nemá moc s realitou co společného, ale dá se u ní velice dobře uplatnit logiku. Je to prostě filozofie jak bojovat s entropií.
-
Zapouzdření se v FP (např. v Haskellu) dá udělat pomocí modulů.
-
První dva důvody jsou jasné. Snad jen k té typové kontrole. Interface (v jazycích jako je Java) jsou hodně šikovné. A používám je právě pro rozšíření typové kontroly. Prostě svážu, co kam smí.
Zapouzdření netuším, jak může být řešeno v procedurálního programování. Ve funkcionálním se možná dají použít uzávěry, ale tomu nerozumím tak dobře.
Hodně mi vyhovuje dekompozice problému na malé logické celky, které si pečlivě navrhnu, rozdělím úlohy, a otestuju. Pak komponuju jednotlivé vztahy objektů, a ty objekty, které jsou špatné, tak přepisuju, nebo vyhodím. Domnívám se, že pokud se problém takto nerozdělí, nelze OOP dobře používat a jen se bastlí. Někde jsem četl, že když má třída více, jak dejme tomu deset metod, je moc velká. Postupem času s tímto tvrzením začínám souhlasit.
OOP považuji za metodiku. Podle mne nemá moc s realitou co společného, ale dá se u ní velice dobře uplatnit logiku. Je to prostě filozofie jak bojovat s entropií.
Zvlastni. Vsechno, co popisujete, muzete delat i v proceduralnim programovani, a kdyz vidim nektere OOP vynalezy, prijde mi to i snazsi. Vzdyt uznejte sam:
1. Interfacy - kdyz nepouzivate dedicnost, je to k nicemu (tim nechci rict, ze je dedicnost neuzitecna, akorat ze bez ni to OOP jaksi postrada smysl). Ve staticky typovanem jazyce program, ktery narusuje interface, vetsinou stejne nezkompilujete a dynamicky typovanemu na typove kontrole nezalezi. A kazda sranda neco stoji. Podle me je typova kontrola diminishing returns, ale to je jen nazor (pro ktery mam dobre duvody na delsi rozpravu).
2. Na zapouzdreni mate modularni system, ve vetsine lepsich jazyku.
3. Na dekompozici problemu se pouzivaji funkce nebo procedury. Proc si lamat hlavu tim, ktera patri do ktere tridy, kdyz jsou ty tridy stejne jen umelym delenim? Pokud v tom chcete mit poradek, je lepsi vhodna jmenna konvence.
Na nektere typy problemu (GUI) je OOP super (vsude tam, kde se hodne dedi). Ale cpat ho vsude? A tvrdit, ze je to v boji s entropii nejaky pokrok?
-
Ale vždyť já netvrdil, že se to v proceduralnim programovani nedá.
1. No, jenže já dědičnost umím využít. Interface používám právě proto, že mi to překladač nedovolí přeložit. Takže to zkuste napsat znova a lépe.
Nebo uveďte příklad, jak by jste v procedurálním programování implementoval obecné rozhraní ICommand, k němu blíže neurčený počet implementací. Přičemž mám továrnu (ta může být funkce), která generuje příkazy, ty se někde sockují, a pak se předají další, třeba funkci, která s nich generuje nějaké výsledky. Jde mi o ten Command. Jako určitě bych to zvládl i v neOOP, ale proč si to komplikovat, ne?
2. Znám moduly v VB (očistec) a v pythonu. Určitě to lze použít. Ale to mám na každou jednu třídu/objekt kačenky vytvořit samostatný modul? Myslím, že v tomto je java pohodlná, že umí třeba i privátní třídy v třídách.
3. Na dekompozici problému se používaji metody a třídy. Proc si lámat hlavu tim, která funkce se používá na kterou strukturu, kdyz je mohu svázat k sobě? Dělat to jen jmennou konvencí mi z toho udělá nepořádek a pak je z toho změť podtržítek.
OOP je v boji proti entropii pokrok, jak by jste chtěl dokázat opak? Proč se většina komplexních systémů píše v Javě, přestože je to nenažraná potvora?
-
Zvlastni. Vsechno, co popisujete, muzete delat i v proceduralnim programovani, a kdyz vidim nektere OOP vynalezy, prijde mi to i snazsi. Vzdyt uznejte sam:
Obávám se, že tohle není argument. Všechny současné jazyky jsou turingovsky kompletní, tzn. že všechny jsou schopny používat OOP techniky bez přímé podpory, protože kód z OOP jazyka lze do jejich jazyka převést.
Tady jde asi o něco jiného a souhlasím s původním příspěvkem. OOP techniky pomáhají hlavně při abstrakci daného problému a to jak při návrhu, tak při jeho údržbě. Dobře rozdělují role a zodpovědnost. Pokud nejsme někde schopni o zodpovědnosti rozhodnout, je program navržen špatně. To se mi osvědčilo už několikrát a vždycky to bylo tím, že jsem dával zodpovědnost té části programu (tomu objektu), který ji neměl dostat.
Výsledkem překlad OOP jazyka je neobjektový strojový kód. O tom, jestli k tomu strojovému kódu dojdeme pomocí OOP jazyka, nebo pomocí jiných technik už tady až tak nehraje roli.
-
JS, vzhledem k tomu, že autor tématu začal o C++, bylo by asi fajn být konkrétnější. C++ bez OOP je takové lepší Céčko (jmenné prostory, konstanty, reference, šablony funkcí a pár dalších věcí, které toho ale řeší relativně málo).
1. Interfacy - kdyz nepouzivate dedicnost, je to k nicemu (tim nechci rict, ze je dedicnost neuzitecna, akorat ze bez ni to OOP jaksi postrada smysl). Ve staticky typovanem jazyce program, ktery narusuje interface, vetsinou stejne nezkompilujete a dynamicky typovanemu na typove kontrole nezalezi.
Explicitní interface podle mě přinejmenším napomáhá porozumění kódu. Svým způsobem je to důležitější koncept než dědičnost.
2. Na zapouzdreni mate modularni system, ve vetsine lepsich jazyku.
Docela by mě zajímalo (teď nerýpu a ptám se), které procedurální jazyky tohle umějí, pokud vůbec.
3. Na dekompozici problemu se pouzivaji funkce nebo procedury. Proc si lamat hlavu tim, ktera patri do ktere tridy, kdyz jsou ty tridy stejne jen umelym delenim? Pokud v tom chcete mit poradek, je lepsi vhodna jmenna konvence.
Některé objektové jazyky mají výhodu, že není nutné explicitně odkazovat na this/self. To je u ukecaných jazyků typu Java určitá výhoda (samozřejmě to má i temnou stránku), protože to snižuje šum v kódu. Že to lze řeši i jinak, je samozřejmě pravda. Ne ale v Javě a v C++ jenom obecně problematickými prostředky preprocesoru.
-
Boneflute, těch kačenek je možné uvnitř jednoho modulu uzavřít tolik, kolik člověk potřebuje (a v té míře, ve které to dává smysl). S pythonovskými moduly bych třeba ty haskellovské nesrovnával, modul v Pythonu zapouzdření řeší jenom malinko (zapouzdření vnitřních funkcí, nikoliv dat).
-
Haskel já neznám. Jen jsem zmínil co znám, to samo o sobě je informace :-)
A naopak, Python zapouzdření řeší, no, svým způsobem. Nemá protected, a přístup k private není zakázaný. Jen je namontován prefixem na třídu, a zapodtržítkovaný. Což je imho taky způsob. Jinak mám za to, že private můžou být i prvky balíčků.
Každopádně neřeším to, zda by to šlo, či ne, ale při představě, že bych tu zapouzdřenost řešil balíčkama - jsem rád, že to nemusím dělat.
-
No, mně nešlo o to, zda lze mít prvky balíčků privátní, nebo ne (__all__ a jeho důsledky), ale o to, že Python na rozdíl od Haskellu neumí exportovat typ tak, aby do něj nebylo vidět (v Haskellu se to dělá exportem typu bez exportu jeho konstruktorů z modulu). Je možné skrýt atributy třídou (do jisté míry, jde to s tím prefixem; každopádně tady už jsme v OOP) nebo implementovat daný typ třeba v C, to ano. V Haskellu existuje ještě další možnost - použít monádu.
-
Byl by jsi schopen vysvětlit, co to monáda je?
-
1. No, jenže já dědičnost umím využít. Interface používám právě proto, že mi to překladač nedovolí přeložit. Takže to zkuste napsat znova a lépe.
To nejak nechapu. Takze ten interface tam mate proto, abyste obesel nejake omezeni?
Nebo uveďte příklad, jak by jste v procedurálním programování implementoval obecné rozhraní ICommand, k němu blíže neurčený počet implementací. Přičemž mám továrnu (ta může být funkce), která generuje příkazy, ty se někde sockují, a pak se předají další, třeba funkci, která s nich generuje nějaké výsledky. Jde mi o ten Command. Jako určitě bych to zvládl i v neOOP, ale proč si to komplikovat, ne?
V proceduralnim programu by se definovala struktura, ktera by obsahovala par ukazatelu na funkce s urcitou typovou signaturou. Pro kazdy prikaz by se definovaly funkce se stejnou signaturou, a ty by se pak predaly. Je to stejne typove bezpecne a interface to nepotrebuje.
Na druhou stranu, muj postoj k interfacum je ponekud ambivalentni. Jak rika Inkvizitor, interface ma urcitou dokumentacni hodnotu, i kdyz u zrovna tohohle si myslim, ze by to jazyk mel resit jinak (nebo spis ze by to mely resit nastroje jako IDE). Vec je, ze nevidim duvod, proc nepovazovat ekvivalentni objekty za ekvivalentni (2 tridy se stejnou podmnozinou metod), aniz by nekdo explicitne prohlasil, ze jsou ekvivalentni (definoval interface). Ale zatim mi neni zcela jasne, jake by to melo dusledky (napriklad pro dispatch metod), takze bych interface uplne nezavrhoval (treba pristup jazyka Go je zajimavy - v tomhle smeru je pak filozoficka otazka, do jake miry jsou interfacy soucasti OOP, nebo je to abstrakce sama o sobe).
2. Znám moduly v VB (očistec) a v pythonu. Určitě to lze použít. Ale to mám na každou jednu třídu/objekt kačenky vytvořit samostatný modul? Myslím, že v tomto je java pohodlná, že umí třeba i privátní třídy v třídách.
No a, tak ten modul bude trochu vetsi. Ja bych se toho nebal. Me prijde, ze tyhle Javove vynalezy se snazi strasne stavet nejruznejsi bariery (delit veci do trid), ktere ve skutecnosti vubec nejsou potreba. Ze bude v jednom modulu par promennych, co spolu nesouvisi? A pak musite delat silene veci (refaktoring pomoci IDE, ruzne patterny), abyste tyhle bariery, ktere jste si nakladli do programu, zase prekonali. Prijde mi to jako prace vynalozena navic, a ta udajna "typova bezpecnost", kterou to prinasi, se v te slozitosti zase ztrati.
Tak mi to proste pripada. Kdykoli prohlizim nejaky program v Jave (bez IDE), je to zoufale. Vsechno je roztahane v bilionu malych souboru v milionech podadresaru. Clovek to proste nemuze vzit a precist si to jako roman.
3. Na dekompozici problému se používaji metody a třídy. Proc si lámat hlavu tim, která funkce se používá na kterou strukturu, kdyz je mohu svázat k sobě? Dělat to jen jmennou konvencí mi z toho udělá nepořádek a pak je z toho změť podtržítek.
Protoze to svazani ma svoji cenu, a za tu platite tim, ze jste si vytvoril umelou barieru, kde tu funkci muzete pouzit. A to vsechno jen za subjektivni pocit toho, co je neporadek.
OOP je v boji proti entropii pokrok, jak by jste chtěl dokázat opak? Proč se většina komplexních systémů píše v Javě, přestože je to nenažraná potvora?
Me se hrozne libi Common Lisp. Nemyslim, ze se v nem nedaji psat komplexni systemy, i bez OOP nadstavby, kterou ma (CLOS). Kdyz ho zacnete studovat, prijdete na to, ze OOP je jen jedna z mnoha abstrakci. Kazda abstrakce je samozrejme pokrok v boji proti entropii, ale nesmi se to prehanet.
Jenze Java to prehnala. Vsechno v zivote zkratka neni trida. Tim se plete puvodni vyznam trid, totiz vyrobit novy typ (coz je to dobre pouziti), s vyznamem "usporadat veci k sobe" (ktery lepe resi modularni system prislusneho jazyka, v pripade CL jsou to balicky a systemy). A to neni dobre.
-
Obávám se, že tohle není argument. Všechny současné jazyky jsou turingovsky kompletní, tzn. že všechny jsou schopny používat OOP techniky bez přímé podpory, protože kód z OOP jazyka lze do jejich jazyka převést.
Je to argument proti tvrzeni, ze OOP prislo nejak vyrazne na pomoc bojovat proti entropii. Historicky to neni pravda. Vzato celkove byl daleko dulezitejsi pro boj s entropii vynalez konceptu funkce (v programovani, ne matematice) nez konceptu tridy. (A ze to trvalo.) A nebo vynalez namespace.
OOP je navic jen jedna z rady abstrakci (nebo spis kombinace nekolika ruznych abstrakci z mnoha), a kazda z nich nejak pomaha v boji proti entropii. Vzit jednu podmnozinu z nich a oznacit ji za dulezitejsi mi prijde scestne.
Tady jde asi o něco jiného a souhlasím s původním příspěvkem. OOP techniky pomáhají hlavně při abstrakci daného problému a to jak při návrhu, tak při jeho údržbě. Dobře rozdělují role a zodpovědnost. Pokud nejsme někde schopni o zodpovědnosti rozhodnout, je program navržen špatně. To se mi osvědčilo už několikrát a vždycky to bylo tím, že jsem dával zodpovědnost té části programu (tomu objektu), který ji neměl dostat.
Jenze tohle bylo vynalezeno pred OOP, tehdy se tomu ovsem rikalo modularni programovani. Takze pripisovat to OOP je odvazne.
-
A uz jen fakt, ze vedeme tuto diskusi, a ze rada velmi chytrych lidi neni zastanci OOP, ukazuje, ze prinos OOP neni tak jednoznacny (spise ale nektere aspekty nekterych jazyku). Nikdo nevede diskuse typu "jste zastanci funkci" nebo "jste zastanci lexikalnich promennych" nebo "jste zastanci predavani jmenem", protoze to uz jsou koncepty, co se jasne ukazaly.
-
A uz jen fakt, ze vedeme tuto diskusi, a ze rada velmi chytrych lidi neni zastanci OOP, ukazuje, ze prinos OOP neni tak jednoznacny (spise ale nektere aspekty nekterych jazyku). Nikdo nevede diskuse typu "jste zastanci funkci" nebo "jste zastanci lexikalnich promennych" nebo "jste zastanci predavani jmenem", protoze to uz jsou koncepty, co se jasne ukazaly.
Jenže to se pletete, protože vše co jste vyjmenoval jsou vyjadřovací prostředky, zatímco OOP je metodika návrhu aplikace a ne vyjadřovací prostředek. OOP jazyky obsahují vyjadřovací prostředky, jako právě ty interfacy, třídy, zápis s tečkou, nástroje pro vytváření objektů, alokace prostřední pro ně (paměť) atd, ale tyhle vyjadřovací techniky jsou určené jen proto, aby usnadňovali naplňovat metodiku OOP.
V zásadě existují dva přístupy návrhu. Klasický strukturalní, nebo databázový, kdy mám data organizované v nějakém storage a funkce, které různě s těmi daty pracují. Tam spadají relační databáze, globální proměnné, zásobníkové algoritmy. OOP naopak drží data pospolu ve skupině s operacemi, které s těmi daty pracují.
Je naprosto šumák, jestli si navrhnete aplikaci v OOP prostředí s objektovou databází, nebo použijete relační databázi, do které budete ukládat serializované struktury. V prvním případě vám objektová databáze půjde naproti a pomůže vám. V tom druhém případě budete vymýšlet obezličky a pak si plácat po ramenou, jak se můžete objektům vyhnout.
Někde tady na forech byl dotaz ohledně speciální databáze k e-shopu, která se velice těžko bude řešit strukturovaně, ale v OOP je to otázka na několik jednoduchých objektů. Takže asi tak
-
V zásadě existují dva přístupy návrhu. Klasický strukturalní, nebo databázový, kdy mám data organizované v nějakém storage a funkce, které různě s těmi daty pracují. Tam spadají relační databáze, globální proměnné, zásobníkové algoritmy. OOP naopak drží data pospolu ve skupině s operacemi, které s těmi daty pracují.
Ted jste smichal tolik veci dohromady, ze fakt nevim, s cim vlastne polemizujete. (Asi je to trochu strawman, protoze jste proti OOP postavil relacni model dat, ktery, podobne jako OOP, neni vselek.)
Pro me maji oba pristupy maji sve vyhody a nevyhody, neni mezi nimi ostre deleni (viz genericke funkce), a nelze rict, ze je jeden z nich horsi nebo lepsi. Vtip je v tom, ze ja se nesnazim dokazat, ze OOP pristup je striktne horsi nez proceduralni. Jen to, ze se to s nim prehani. Konkretne napriklad, nemam pocit, ze Linuxove jadro je horsi program jen proto, ze ovladace zarizeni nejsou objekty.
-
Konkretne napriklad, nemam pocit, ze Linuxove jadro je horsi program jen proto, ze ovladace zarizeni nejsou objekty.
Já ano. Mimochodem, oni jsou to objekty. Kolikrát napsané v čistém C. Místo interfaců tam najdete třeba tabulky funkcí. Když se podíváte, jak jsou implementované interfacy, zjistíte, že to jsou tabulky funkcí. Jde o to, že tabulka funkcí se rychleji implementuje pomocí interface, než pomocí tabulky funkcí v čistém C. Asi tak 100x.
Další výhodou je, že zatímco v čistém C si každý autor udělá "ty svoje objekty", dá si k nim svoje pravidla, C++ zavádí jednotná pravidla, jak tyhle objekty a tabulky funkcí implementovat. A programátor se soustředí až na využití těchto technik a neřeší, jestli jeho kolega udělal ten interface jako pointer nebo jako dva pointery, nebo jako pointer na pointer, nebo tu tabulku narval přimo do te struktury představující objekt.
(mimochodem, doporučuju tento článek: http://zdrojak.root.cz/clanky/konec-starych-programatorskych-casu/ )
-
To nejak nechapu. Takze ten interface tam mate proto, abyste obesel nejake omezeni?
Ne, naopak. To interface tam mám proto, aby na mě překladač řval, když se uklepnu.
Vec je, ze nevidim duvod, proc nepovazovat ekvivalentni objekty za ekvivalentni (2 tridy se stejnou podmnozinou metod), aniz by nekdo explicitne prohlasil, ze jsou ekvivalentni (definoval interface).
Tak na to jsem našel někde příklad, který mne přesvědčil:
class Loď:
def potopit():
pass
class Potápěč:
def potopit():
pass
inst.potopit()
No a, tak ten modul bude trochu vetsi. Ja bych se toho nebal. Me prijde, ze tyhle Javove vynalezy se snazi strasne stavet nejruznejsi bariery (delit veci do trid), ktere ve skutecnosti vubec nejsou potreba.
No, v tom je ten problém. Mě ty Javovské vynálezy vyhovují. A mě ty bariéry pomáhají. Pro mě jsou potřeba. Je to stejné, jako když má auto kapotu, který vypne nastartování. Můžete tam zmáčknout ten čudlík, a tím tuto ochranu obejít, ale faktem je, že je dost užitečné, že se vám auto nerozjede když se mu vrtáte v motoru. Takové ochrany jsou v tiskárně, v cirkulárce, v ledasčems. A považuji to za výhodu, ne zbytečné omezování.
Opravdu hodně by mě vadilo, když bych měl v jednom modulu věci, které spolu nesouvisejí, a které umožňují interakce = sideoefect, když je špatně použiju. To by mi opravdu hodně vadilo.
Je to jeden ze základů programování, který ctím. Žádné sideefekty, páč, když se k tomu po čase vrátím, tak to musí být naprosto jasné.
Protoze to svazani ma svoji cenu, a za tu platite tim, ze jste si vytvoril umelou barieru, kde tu funkci muzete pouzit. A to vsechno jen za subjektivni pocit toho, co je neporadek.
Já tam žádnou cenu nevidím.
Pokud je to funkce/metoda patřící k oběktu, tak ji jinde použít nechci.
Pokud je to funkce, která k tomu objektu nepatří, tak o tom se nebavíme.
Takže jaká cena? Jaká umělá bariéra? Nerozumím.
Me se hrozne libi Common Lisp. Nemyslim, ze se v nem nedaji psat komplexni systemy, i bez OOP nadstavby, kterou ma (CLOS). Kdyz ho zacnete studovat, prijdete na to, ze OOP je jen jedna z mnoha abstrakci. Kazda abstrakce je samozrejme pokrok v boji proti entropii, ale nesmi se to prehanet.
Mě se Lisp také líbí. A s tímto textem s vámi souhlasím.
Jenze Java to prehnala. Vsechno v zivote zkratka neni trida.
Dle mého má java jiné problémy, než že to přehnala. A druhak, když si přečtete znovu můj první příspěvek, já jsem netvrdil, že OOP reflektuje realitu. Podle mne vůbec. Podle mne je OOP metodika, jak popsat problém, a jak bojovat s entropií a vlastní blbostí. V tom je OOP velmi dobré.
Tim se plete puvodni vyznam trid, totiz vyrobit novy typ (coz je to dobre pouziti), s vyznamem "usporadat veci k sobe" (ktery lepe resi modularni system prislusneho jazyka, v pripade CL jsou to balicky a systemy). A to neni dobre.
S tím bych nemohl souhlasit.
Žádný původní význam tříd neznám. Třída definuje a) datovou strukturu, b) přístup k prvků datové struktury, c) metody nad objektem/zprávy objektu. a) definuje typ, b) a c) se sice dá dá dělat pomocí modulů, dokonce i v Javě, ale ty třídy to prostě lépe reprezentují. Je to v jednom chumlu. To se mi líbí, to mi přijde čitelné. Proč by to nebylo dobré? Proč by jste ty metody/funkce odtrhával a dával někam pryč?
-
Já ano. Mimochodem, oni jsou to objekty. Kolikrát napsané v čistém C. Místo interfaců tam najdete třeba tabulky funkcí. Když se podíváte, jak jsou implementované interfacy, zjistíte, že to jsou tabulky funkcí. Jde o to, že tabulka funkcí se rychleji implementuje pomocí interface, než pomocí tabulky funkcí v čistém C. Asi tak 100x.
Ja tedy ten pocit nemam. Udelat tabulku funkci znamena v podstate tu stejnou praci - definujete signatury funkci ve strukture, definujete ty clenske funkce, definujete tu tabulku. Pokud byste chtel neco jako dedicnost, muzete tam dat nulovy odkaz, a hned vidite, zda ten objekt tu metodu implementuje nebo ne. S interfacy by tohle bylo pres ruku, protoze musite definovat vic interfacu, zjistovat, zda funkce podporuje dany interface .. atd. (Ale jak je definovat? Ruzna zarizeni maji ruzne pozadavky a ty se muzou ruzne krizit.) A jak rikas dal, lze to implementovat ruzne, takze pouzit abstrakci z jazyka me zavazuje k urcitemu druhu implementace. Je zrejme, ze oboji sve vyhody a nevyhody, tak proc se prit? (Ostatne, mam pocit, ze tohle zacina duplikovat tvou predchozi diskusi s Blekem.)
Proste, OOP je abstrakce jako kazda jina, nema smysl se prit. Je jasne, ze by vyvojari Linuxu usetrili, kdyby se rozhodli psat ho v jazyce s makry (myslim poradna makra, ktera dovoluji definovat veci jako OOP, ne jen C makra, i ta jim ale dost pomahaji). Ovsem takovy jazyk na trhu neni (mozna se tomu blizi Forth).
-
Ne, naopak. To interface tam mám proto, aby na mě překladač řval, když se uklepnu.
No, stale mi prijde, ze vam to sice chyby najde, ale za cenu vetsiho psani, takze nula od nuly pojde. Rad bych videl priklad. Dejme tomu, ze to mame implementovane proceduralne pres tabulku. Jakym druhum chyb zabrani implementovat to pres rozhrani?
Tak na to jsem našel někde příklad, který mne přesvědčil:
...
Mel jsem podobny priklad v hlave, kdyz jsem to psal, ale moc jsem to nezkoumal. Na prvni pohled je to asi pravda, ale i tak mi prijde, ze to za tenhle (ne az tak casty) omyl moc nestoji, definovat vsude interface. A kdybyste bral interface jako zpusob, jak predejit jmennym konfliktum, tak vam to stejne nepomuze, az budete chtit zavest tridu Ponorka. Budu se nad tim muset jeste zamyslet, zda neexistuje lepsi reseni; je to legitimni problem.
No, v tom je ten problém. Mě ty Javovské vynálezy vyhovují. A mě ty bariéry pomáhají. Pro mě jsou potřeba. Je to stejné, jako když má auto kapotu, který vypne nastartování. Můžete tam zmáčknout ten čudlík, a tím tuto ochranu obejít, ale faktem je, že je dost užitečné, že se vám auto nerozjede když se mu vrtáte v motoru. Takové ochrany jsou v tiskárně, v cirkulárce, v ledasčems. A považuji to za výhodu, ne zbytečné omezování.
Me se libi Paul Grahamova filozofie, ze nejprve se ten program vytvori na hrubo, a pak se pozdeji vylepsuje a stabilizuje (asi se tomu rika rapid-prototyping?). Proto se na to divam z hlediska hypotetickeho budouciho jazyka, ktery na zacatku necha programatorovi velkou svobodu, a teprve pozdeji (castecne nezavisle na funkcnim kodu, a castecne na zkusenosti z jeho chovani) pomuze programatorovi vztycit tyto bariery a najit tak dalsi chyby. Zatim takovy jazyk neni, Common Lisp se mu blizi, ale aniz by si to nejak uvedomoval. Takze ja jsem spis proti predcasnemu staveni techto barier (a jejich fakticke nemoznosti je pozdeji ignorovat).
Opravdu hodně by mě vadilo, když bych měl v jednom modulu věci, které spolu nesouvisejí, a které umožňují interakce = sideoefect, když je špatně použiju. To by mi opravdu hodně vadilo.
Nevim. Snazit se definovat vsechno tak, aby byly nezavisle veci maximalne explicitne oddelene mi prijde jako diminishing returns. Od jiste urovne detailu uz se to proste nemuze vyplatit. Ale jinak bych s tim souhlasil, ale nemyslim, ze to je neco, co prinesl OOP pristup.
Já tam žádnou cenu nevidím.
Pokud je to funkce/metoda patřící k oběktu, tak ji jinde použít nechci.
Pokud je to funkce, která k tomu objektu nepatří, tak o tom se nebavíme.
Takže jaká cena? Jaká umělá bariéra? Nerozumím.
Co kdyz ta funkce pracuje s vic nez jednim objektem? Pak ji priradit konkretnimu z nich je umela bariera.
Žádný původní význam tříd neznám. Třída definuje a) datovou strukturu, b) přístup k prvků datové struktury, c) metody nad objektem/zprávy objektu. a) definuje typ, b) a c) se sice dá dá dělat pomocí modulů, dokonce i v Javě, ale ty třídy to prostě lépe reprezentují. Je to v jednom chumlu. To se mi líbí, to mi přijde čitelné. Proč by to nebylo dobré? Proč by jste ty metody/funkce odtrhával a dával někam pryč?
Existuji jiste i funkce, ktere zadny novy typ nepotrebuji (a odpada tak duvod mit je v tride). Stejne tak, existuji funkce, ktere zpracovavaji vice ruznych typu. Tohle IMHO krasne resi v CLOSu genericke funkce. Proto je dobre funkce (alespon nektere) odtrhnout od datovych typu. Co kdyz si date funkci dvou typu do tridy toho prvniho, a pozdeji ji budete chtit rozsirit v tom druhem (ale kod muze zustat stejny)? OOP v Jave vam v tom zabrani, v CLOSu (nebo Go, ktere tento napad tusim prejalo) to bude snadne.
-
No, stale mi prijde, ze vam to sice chyby najde, ale za cenu vetsiho psani, takze nula od nuly pojde. Rad bych videl priklad. Dejme tomu, ze to mame implementovane proceduralne pres tabulku. Jakym druhum chyb zabrani implementovat to pres rozhrani?
No, to já hlavně nevím jak by to fungovalo přes tabulku...
Interface mi zajistí, že objekt, který přišel má metodu getIvoicer() a getRule(). Díky tomu mohu v kódu napsat něco jako:
inst.getInvoicer().process(inst.getRule)
Já už jsem z céčka vypadl, ale v Pythonu bych musel po vstupu kontrolovat, zda ty metody ten objekt má. Klasické duck typing. Navíc, když vytvořím implementaci nějaké struktury, nesoucí tuto logiku, tak mě to nezkontroluje, že jsem zapoměl na jednu metodu dokavad to nepoužiju. V praxi samozřejmě to bude tak, že problémy vzniknou až v okamžiku refactoringu.
Tedy shrnuto, rozhraní zajištuje:
Že funkci/metodě předávám správný objekt. Třeba, že mi tam něco neuteklo.
Že objekt implementuje všechny povinné metody.
Me se libi Paul Grahamova filozofie, ze nejprve se ten program vytvori na hrubo...
To je sice hezký, ale má to dva háčky: Jednak je to metodika, kterou se budou muset lidé naučit. Já třeba podobný přístup v pythonu opustil, protože mě iritovalo, jak to furt nefunguje - tedy je to přesný opak XP. A druhý háček je v tom, že jak sám říkáte, nemáme implementaci do jazyka.
A tady se bavíme o tom, zda jsme zastánci OOP, ne co je nejlepší. Nejlepší je Ferda, to už víme.
Nevim. Snazit se definovat vsechno tak, aby byly nezavisle veci maximalne explicitne oddelene mi prijde jako diminishing returns.
No, moje zkušenost je taková, že když si práci zjednoduším, a dělám noname objekty s veřejnými atributy, tak pak honím chyby po všech čertech. Takže já prohlašuji, že je to ještě daleko před tou hranicí.
nemyslim, ze to je neco, co prinesl OOP pristup
Podle wikipedie, je zapouzdření jedním ze základních kamenů OOP. Céčko, Paskal, nedejbože Basic zapouzdření před příchodem Smalltaku, Objective C, nebo C++ neumožňovali. Takže já si myslím, že to OOP přístup přinesl.
Co kdyz ta funkce pracuje s vic nez jednim objektem? Pak ji priradit konkretnimu z nich je umela bariera.
Ano. Je. Proč bych takovou kravinu dělal?
Existuji jiste i funkce, ktere zadny novy typ nepotrebuji (a odpada tak duvod mit je v tride).
Samozřejmě. No a? To není nic proti OOP. Prostě mám izolované funkce, které nějakým způsobem pracují s objekty. Pokud si to jazyk vynucuje je přiřadit nějaké třídě (Java), tak si na to vytvořím třídu. Nejdřív budu prskat, jako vy, že je to zbytečnost, ale pak zjistím, že vlastě ještě potřebuju, aby tu funkci používali jen a pouze tyto a tyto třídy, a tak spřísním oprávnění a umístím to do modulu. Nakonec zjistím, že to stejně někam umístit musím, ve vzduchu to bejt nemůže.
Fajn, v čem je problém?
Po pravdě řečeno, když bych měl projekt, ve kterém by se tato situace stávala často, pravděpodobně bych změnil styl, nebo jazyk. A nedělal to dle OOP. V mé praxi je to ale přesně naopak. Většinou těchto izolovaných funkcí je minimum. A to prosím nedělám GUI.
Co kdyz si date funkci dvou typu do tridy toho prvniho, a pozdeji ji budete chtit rozsirit v tom druhem (ale kod muze zustat stejny)?
Nevím zda vám rozumím. Není to ten samej problém co víše?
-
Co kdyz ta funkce pracuje s vic nez jednim objektem? Pak ji priradit konkretnimu z nich je umela bariera.
Můžete si vybrat. Záleží zpravidla na tom, jak který objekt má blíže k operaci té funkce.
obj.save(stream)
nebo
stream.save(obj)
?
No v tom prvním případě musí obj znát stream. V tom druhém musí stream znát obj. Pokud chci psát univerzální streamy, a objekty, které se chtějí serializovat do streamu, pak volím první metodu, protože stream nic o objektech vědět nemusí, ale objekty ano.
(jde o to, že abych mohl deklarovat metodu save u objektu, musím říct co je stream. Pokud to budu chtít deklarovat u streamu, musím dodat objekt. Je zde taky docela pěkně vidět zodpovědnost. V prvním případě je za uložení do streamu zodpovědný objekt sám. V druhém případě tu zodpovědnost nese stream, což uznáte, že je blbost)
-
Vec je, ze nevidim duvod, proc nepovazovat ekvivalentni objekty za ekvivalentni (2 tridy se stejnou podmnozinou metod), aniz by nekdo explicitne prohlasil, ze jsou ekvivalentni (definoval interface).
Tak na to jsem našel někde příklad, který mne přesvědčil:
class Loď:
def potopit():
pass
class Potápěč:
def potopit():
pass
inst.potopit()
Tak tohle je přesně věc, která se mi na těch tzv. "čistě objektových" jazycích vůbec nelíbí. Loď a potápěč je něco absolutně jiného a v tomto kontextu i potopení daného objektu je odlišná akce, s diametrálně odlišnými důsledky. Zlatá typová kontrola C++...
-
Tak tohle je přesně věc, která se mi na těch tzv. "čistě objektových" jazycích vůbec nelíbí. Loď a potápěč je něco absolutně jiného a v tomto kontextu i potopení daného objektu je odlišná akce, s diametrálně odlišnými důsledky. Zlatá typová kontrola C++...
To není vlastnost "čistě objektových" jazyků, to je vlastnost jazyků používajících duck typing (http://en.wikipedia.org/wiki/Duck_typing). V duck-typingu a ve strukturálních typových systémech (http://en.wikipedia.org/wiki/Structural_type_system) můžou být typy kompatibilní i bez toho, aby tak byly explicitně deklarovány. V typovém systému, který má C++, na to explicitně deklarovány být musí - je to tzv. nominální typový systém (http://en.wikipedia.org/wiki/Nominative_type_system).
S tím, jestli je jazyk čistě objektový (jako např. Ruby - to neobsahuje žádné jiné datové typy než třídy), to nemá nic společného. Mimochodem, Python čistě objektový není.
-
Vy sa tu hádate čo je lepšie a ja furt neviem o čom... Každý o tom hovorí, už mi ľudia posielali siahodlhé články, ale nikde v tých tonách slov som nevidel príklad a uvedené rozdiely (ne)OOP programovania.
Mohol by mi to prosím niekto vysvetliť (najlepšie na nejakom príklade v PHP, ale v podstate je to jedno)? Ďakujem.
-
Vy sa tu hádate čo je lepšie a ja furt neviem o čom... Každý o tom hovorí, už mi ľudia posielali siahodlhé články, ale nikde v tých tonách slov som nevidel príklad a uvedené rozdiely (ne)OOP programovania.
Mohol by mi to prosím niekto vysvetliť (najlepšie na nejakom príklade v PHP, ale v podstate je to jedno)? Ďakujem.
Tak třeba porovnejte API GTK a QT.
Nebo Windows GUI a Javovské GUI.
Třeba najednou přijdete na to, proč Windows mají pro každou blbost okno. No jasně, oni totiž mají pouze jeden "objekt", který funguje jako holka na všechno. Zatímco v Javovském GUI máme listenery a interface a takovy věci.
Pak člověk řeší třeba takové věci, proč zpráva z menu se handluje přes okno (který nemusí s menu mít nic společného) ve windows, zatímco v Javě přes listener spojený přímo s tím menu.
Ono je to právě všechno v tom navrhu a jít na to neobjektově, pak člověk hledá způsoby jak si ušetřit práci znásilňováním věci, které původně byly určeny pro něco jiného, ale protože mají určitou specifickou vlastnost, tak se to znásilní. Okna ve Windows mají schopnost přijímat zprávy, protože potřebují vědět, kdy se mají nakreslit, nebo kdy se do nich kliklo. Proto když chce člověk přijmout například zprávu o tom, že na soket došla data, co použije... no jasně, znásilní si okno :) , namísto toho, aby k soketu zaregistroval rozhraní, na němž se vyvolá patřičná funkce, která vykoná obsluhu dané akce.
-
To není vlastnost "čistě objektových" jazyků, to je vlastnost jazyků používajících duck typing (http://en.wikipedia.org/wiki/Duck_typing). V duck-typingu a ve strukturálních typových systémech (http://en.wikipedia.org/wiki/Structural_type_system) můžou být typy kompatibilní i bez toho, aby tak byly explicitně deklarovány. V typovém systému, který má C++, na to explicitně deklarovány být musí - je to tzv. nominální typový systém (http://en.wikipedia.org/wiki/Nominative_type_system).
S tím, jestli je jazyk čistě objektový (jako např. Ruby - to neobsahuje žádné jiné datové typy než třídy), to nemá nic společného. Mimochodem, Python čistě objektový není.
Ok, i když si myslím, že podobného efektu by šlo dosáhnout už jen s pomocí pozdní vazby.
Nic to však nemění na tom, že se mi nelíbí možnost, pouze díky shodě rozhraní či podobnosti hodnoty, zaměnit dva naprosto odlišné objekty (což v C++ už tak jednoduché není. Tedy pokud nejsou potomky jedné třídy, ale pak je už nepovažuji za naprosto odlišné.... ). Tedy chci, aby se potopil potápěč a ... pošlu ke dnu celou letadlovou loď...
-
me v posledni dobe zaujal rozhovor s Alanem Kayem, mimo jine tam vysvetluje motivace zavedeni pojmu OOP, zminuje jednak nejaky vektorovy kreslici program, druhak priklad s nejakymi vojenskymi depesemi + problemy s jejich zpracovanim (+ protipriklad weboveho prohlizece a html); ten druhy zejmena mi prijde jako jadro te puvodni myslenky - dorucit data spolecne s kodem, ktery s nimi bude umet pracovat, protoze neni dobre spolehat na to, ze druha strana umi s onemi daty vubec spolupracovat, druha strana proste jen pouzije ten kod, co to umi
tohle je na hony vzdalene tomu, co se tim mysli dnes, dle me je uzitecne rozdelit OOP z pohledu - 1.) modelovani reality pri reseni problemu, protoze je to prirozene (a velmi casto "prirozene") 2.) metodika vytvareni programu, ktera s tim Kayovym pohledem nema jiz mnoho spolecneho (on mimo jine dodava "extreme late binding on everything")
takovou funkce sin(x) zjevne z toho 1. pohledu nema VUBEC ZADNY smysl umistovat do jakekoli tridy, ze, ale dela se to kvuli tomu 2. pohledu, protoze trida vetsinou implikuje namespace napr. a nejaky pocit, ze "je to pohromade" (treba s cosinem)..
ad metodika - resp. ze funkce (potazmo strukturovane programovani) metodika nejsou; samozrejme jsou, popreni je jako rici, ze pred C++ nebo Javou se nic velkeho nedelalo (delalo, nedelaly to hordy nahraditelnych "lidskych zdroju")
ad potapec/ponorka - a proc bych pro situaci, kdy chci mit naprostou jistotu, volil neco, co mi ji neda? kdyz mi ji to neda? stejne jako proc bych tam nenapsal ten runtime test rucne (v jazycich s duck typingem), kdyz bych ji opravdu chtel mit? na co presne to ma ukazovat? ze dynamicka typova kontrola je horsi? je jina a ma jine vyhody; megaobev, gratuluju
vzhledem k tomu, jak moc se Java uchytila v korporatnu, pocitam, ze to je z duvodu preneseni jadra vykonu povolani z porozumeni/premysleni na schopnost vyhledavani v dokumentaci/neskodneho (to je asi opravdu plus Javy) dobastlovani (tozn. vymeni se clovek a muze, protoze browsit tridy a jejich dokumentaci ve standardnim formatu je zvykly, pokracovat v tom, co nekdo zkusenejsi navrhl), coz je neco, co se univerzalnim hnedym manazerum, kteri chteji "zastupitelnost", "jistotu" a ordnung nejspis libi..
-
Byl by jsi schopen vysvětlit, co to monáda je?
Monáda je (zjednodušeně řečeno) krabice na nějaký typ, která má dvě základní operace, return pro vytvoření monády a bind, která umožňuje transformaci obsahu a vytvoření jiné monády. Používá se v Haskellu mimo jiné pro práci s I/O a definici sekvence akcí (čistý Haskell je v podstatě jedna velká transformace vstupních dat na výstupní a explicitní sekvence akcí nedefinuje).
Nicméně jsem se nad tím zamýšlel a monáda bez modulu zapouzdření moc neřeší, takže se omlouvám za zbrklý výrok.
-
jeste k ponorce/potapecovi - co presne to melo dokazovat?
1.) ze ve staticky typovanem jazyku mi instance.potop nikdy nepotopi ponorku? japato, co kdyz jsem se upsal a potapim prave instanci ponorky? typechecker to prohlasi za ok, chyba je v semantice, stejne jako kdyz se upisu v dynamicky typovanem
2.) ze ve staticky typovanem jazyce rychle najdu (= zjistim potencialni chybu) mista, kde potapim ponorku diky typovym deklaracim (i v hlavickach funkci/metod)? no japabyne, kdyz ty typy vsude pisu resp. znovu a znovu opisuju, bez toho ten typechecker nepremava!
-
Nic to však nemění na tom, že se mi nelíbí možnost, pouze díky shodě rozhraní či podobnosti hodnoty, zaměnit dva naprosto odlišné objekty (což v C++ už tak jednoduché není. Tedy pokud nejsou potomky jedné třídy, ale pak je už nepovažuji za naprosto odlišné.... ). Tedy chci, aby se potopil potápěč a ... pošlu ke dnu celou letadlovou loď...
To se mi taky nelíbí. Na druhou stranu je to jednodušší, pružnější.
1.) ze ve staticky typovanem jazyku mi instance.potop nikdy nepotopi ponorku? japato, co kdyz jsem se upsal a potapim prave instanci ponorky? typechecker to prohlasi za ok, chyba je v semantice, stejne jako kdyz se upisu v dynamicky typovanem
Japato: protože je tam explicitně napsaný typ. Mám třeba nějakou funkci, která má na starosti ponor potápěče na určitém místě a té dám jako parametr potápěče:
void ponor(Potapec& p, double zem_sirka, double zem_delka) {
//...
p.ponor();
// ...
}Taková funkce nemůže potopit ponorku, protože p nemůže být ponorka, může to být jenom potápěč. Nejde jí předat místo potápěče něco jiného, překladač by zahlásil chybu a program by nepřeložil. Pokud se program přeloží, je zaručeno, že funkce ponor() pracuje vždycky jen s potápěčem a nikdy s ničím jiným.
-
Pánové, prosím vás, k tomu Duck typingu - veškerý fór je v tom, že zatímco duck typing prohlašuje, že "chodí to jako kachna, plave to jako kachna, kváká to jako kachna - je to kachna", od toho to má i to jméno, tak klasicky, bez duck typingu se pracuje tak, že "Je to kachna? Sice to kváká, plave, chodí jako kachna, ale má to na sobě cedulku, že je to veterán z vojny, takže to kachna není."
Takže k tomu potápěči to dokazuje jen to, že nemůže dojít k omylu na základě shody metod. Nic víc, nic méně.
-
duck typing prohlašuje, že "chodí to jako kachna, plave to jako kachna, kváká to jako kachna - je to kachna", od toho to má i to jméno, tak klasicky, bez duck typingu se pracuje tak, že "Je to kachna? Sice to kváká, plave, chodí jako kachna, ale má to na sobě cedulku, že je to veterán z vojny, takže to kachna není."
Bez urážky ale z toho čo som prečítal tak na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP a preto tu splietate takéto nezmysli o kachnách. Sú to naozaj drísty. Na roote by sa mala zaviesť sekcia vtipy a všetky príspevky z tohoto threadu do nej presunúť.
-
Bez urážky ale z toho čo som prečítal tak na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP a preto tu splietate takéto nezmysli o kachnách. Sú to naozaj drísty. Na roote by sa mala zaviesť sekcia vtipy a všetky príspevky z tohoto threadu do nej presunúť.
Duck typing se podle toho fakt jmenuje, uvádí se to typicky jako přirovnání, nevymyslel to nikdo tady.
-
Bez urážky ...
Pokračuj v cestě...
-
... na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP ...
Já se programováním neživím, je to jen můj koníček, OOP nesnáším a nepoužívám, ale co je Duck typing vím velmi dobře a ctím moudrost člověka, který tohle přirovnání vymyslel. Řekl bych tedy, že tvůj výrok pasuje především na tebe ;-)
Mimochodem, když jsem stejný "kachní" citát použil na Laela, tak také nepochopil, ale to je starší člověk který dnešní technologie už moc nestíhá...
-
... na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP ...
Já se programováním neživím, je to jen můj koníček, OOP nesnáším a nepoužívám, ale co je Duck typing vím velmi dobře a ctím moudrost člověka, který tohle přirovnání vymyslel. Řekl bych tedy, že tvůj výrok pasuje především na tebe ;-)
Mimochodem, když jsem stejný "kachní" citát použil na Laela, tak také nepochopil, ale to je starší člověk který dnešní technologie už moc nestíhá...
Rozdíl mezi klasickým duck typingem a OOP je v tom, že zatímco u duck typingu vám stačí najít společné znaky, které jsou pro daný typ objektu typické, tak u OOP je musíte takto označit. Abych argumentoval v podobném duchu jako klasický duck test:
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
Slovíčko probably je tady hodně důležité. Mě třeba dost vadí.
-
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
Slovíčko probably je tady hodně důležité. Mě třeba dost vadí.
Myslím, že není problém si pohlídat, aby v metodě šly zpracovávat opravdu jenom objekty typu "kachna". V Pythonu apod. ale až v době běhu programu; což je podle mě větší problém, než samotný duck typing. Ten je IMO neškodný, ale pokud program (třeba v Pythonu) až při běhu zjistí, že ten objekt nemá metodu swim, je to průšvih. Ale to je problém dynamických jazyků obecně. V praxi to obvykle tak často nevadí.
Nedávno jsme narazili v jednom projektu na podobný problém - kolega použil omylem v jednom volání numerickou konstantu podobne vyhlížející, ale patřící do jiné kategorie. To by se mu stalo i v C++ a problematiku OOP to přesahuje. Primárně jde o rozumně definované typy. Pokud se nepletu, enum by v C++ nepomohl a dělat si na každou kategorii konstant speciální třídu je strašlivý opruz.
-
Rozdíl mezi klasickým duck typingem a OOP je v tom, že zatímco u duck typingu vám stačí najít společné znaky, které jsou pro daný typ objektu typické, tak u OOP je musíte takto označit.
To je blábol, OOP vůbec není v rozporu duck typingem. OOP není typový systém, je blbost porovnávat OOP a nějaký typový systém. Různé OOP jazyky mají různé typové systémy.
-
Rozdíl mezi klasickým duck typingem a OOP je v tom, že zatímco u duck typingu vám stačí najít společné znaky, které jsou pro daný typ objektu typické, tak u OOP je musíte takto označit.
To je blábol, OOP vůbec není v rozporu duck typingem. OOP není typový systém, je blbost porovnávat OOP a nějaký typový systém. Různé OOP jazyky mají různé typové systémy.
Omlouvám se za zkratku. Myslel jsem tím OOP se statickým typováním. To do OOP patří.
Přiřazování do tříd je velmi oblíbenou technikou v OOP, akorát je třeba umět přiřadit objekt do vícero tříd, což je třeba problém Javy a jiných jazyků, jdoucí třetí cestou.
Příklad kachny jako objektu, který patří do třídy plavající, kvákající a vypadající jako kachna.
-
duck typing prohlašuje, že "chodí to jako kachna, plave to jako kachna, kváká to jako kachna - je to kachna", od toho to má i to jméno, tak klasicky, bez duck typingu se pracuje tak, že "Je to kachna? Sice to kváká, plave, chodí jako kachna, ale má to na sobě cedulku, že je to veterán z vojny, takže to kachna není."
Bez urážky ale z toho čo som prečítal tak na tomto fóre je naozaj minimum ludí, ktorí vedia programovať a rozumejú OOP a preto tu splietate takéto nezmysli o kachnách. Sú to naozaj drísty. Na roote by sa mala zaviesť sekcia vtipy a všetky príspevky z tohoto threadu do nej presunúť.
Myslím, že by jsi tu sekci s takovými prohlášeními vedl, to jednak. Druhak, nikde jsem o sobě nepsal, že jsem nějaký excelentní programátor, programování je pro mě odreagování a zábavný druh seberealizace, avšak v žádném případě filozofie a smysl života - takže si na rozdíl od tebe uvědomuji, že nemám patent na rozum a nemám potřebu bez nějakých argumentů shazovat někoho jiného, kdo daný problém vidí jinak, nebo zastává trochu jiný názor.
-
Přiřazování do tříd je velmi oblíbenou technikou v OOP, akorát je třeba umět přiřadit objekt do vícero tříd, což je třeba problém Javy a jiných jazyků, jdoucí třetí cestou.
Příklad kachny jako objektu, který patří do třídy plavající, kvákající a vypadající jako kachna.
To jde dobře v prototypových jazycích, např. Javascript. Kam objekt patří je určeno jeho atributy (vlastnostmi) - tj. duck typing; nejsou tam žádné třídy. Python používá taky duck typing na určení, kam objekt patří, ale třídy narozdíl od prototypových jazyků má - objekty patřící do jedné třídy můžou sdílet atributy a metody (tzv. třídní atributy a metody).
-
To není vlastnost "čistě objektových" jazyků, to je vlastnost jazyků používajících duck typing (http://en.wikipedia.org/wiki/Duck_typing). V duck-typingu a ve strukturálních typových systémech (http://en.wikipedia.org/wiki/Structural_type_system) můžou být typy kompatibilní i bez toho, aby tak byly explicitně deklarovány. V typovém systému, který má C++, na to explicitně deklarovány být musí - je to tzv. nominální typový systém (http://en.wikipedia.org/wiki/Nominative_type_system).
Diky, tohle jsem hledal. Vedel jsem, ze jsem tak nejak fanda strukturalniho systemu a ne nominalniho (zejmena co se tyce interfaces), ale nevedel jsem, ze to rozliseni existuje.
-
To jde dobře v prototypových jazycích, např. Javascript. Kam objekt patří je určeno jeho atributy (vlastnostmi) - tj. duck typing; nejsou tam žádné třídy. Python používá taky duck typing na určení, kam objekt patří, ale třídy narozdíl od prototypových jazyků má - objekty patřící do jedné třídy můžou sdílet atributy a metody (tzv. třídní atributy a metody).
No ale kdyz chcete mit dispatch (tj. virtualni metody), tak prece musite nejak oznacit ten typ. Nemuzete vsechno resit jen strukturalne.
-
Me se libi Paul Grahamova filozofie, ze nejprve se ten program vytvori na hrubo, a pak se pozdeji vylepsuje a stabilizuje (asi se tomu rika rapid-prototyping?). Proto se na to divam z hlediska hypotetickeho budouciho jazyka, ktery na zacatku necha programatorovi velkou svobodu, a teprve pozdeji (castecne nezavisle na funkcnim kodu, a castecne na zkusenosti z jeho chovani) pomuze programatorovi vztycit tyto bariery a najit tak dalsi chyby. Zatim takovy jazyk neni, Common Lisp se mu blizi, ale aniz by si to nejak uvedomoval. Takze ja jsem spis proti predcasnemu staveni techto barier (a jejich fakticke nemoznosti je pozdeji ignorovat).
Já myslím, že jak Lisp (a nejen Common), tak Forth se tomu blíží ze všech nejvíc. V těchto jazycích programuji tak, že nejdřív inkrementálně zmatlám něco dohromady - ono totiž ani při nejlepší vůli není možné dopředu odhanout všechny detaily, jež se člověku nachomýtnou přes cestu a z některých těch zdánlivých detailů se mohou vyklubat pěkné oříšky - a pak to udělám z jedné vody načisto. To v podstatě doporučuje i Chuck Moore (kolik let před Grahamem? :-) Ovšem už se znalostí těch problémů a vytvořiv si k tomu potřebné syntaktické nástroje, v jejichž rámci a s jejichž pomocí to budu realisovat.
-
No ale kdyz chcete mit dispatch (tj. virtualni metody), tak prece musite nejak oznacit ten typ. Nemuzete vsechno resit jen strukturalne.
V duck typingu samozřejmě virtuální metody fungují, ale jsou řešeny jinak. Objekt tam s sebou nese jména svých členů a dispatch tak řeší program za běhu (prostě řeknete objektu jméno metody, kterou chcete volat, a on vám ji dodá). U nominálně typovaných jazyků objekty nenesou jména svých členů a dispatch tak řeší kompilátor (rovnou určí, kde v objektu bude umístěn ukazatel na příslušnou metodu, nemusí se hledat v mapě členů). Výhody a nevýhody jsou zřejmé: druhé stojí méně paměti a výkonu, ale omezuje možnosti dynamických změn chování.
Ještě existuje střední cesta, kterou se vydalo třeba Qt. Je sice nominálně typované, takže většina dispatchů řeší kompilátor, ale stále si nese s sebou i jména členů tříd a tedy lze v nich i dynamicky hledat jako v duck typingu. Stojí to paměť, ale hledá se, jenom když to jinak nejde.
-
Při psaní šablon (kde objektem je "typ") používáme taku duck typing. Ale občas by se nějaký interface hodil. Když překladač při instanciování šablony zjistí, že nějaký typ nějaké metody neposkytuje, tak se ta chyba dost blbě loví.
-
Jsem, ale není nutno je používat dogmaticky vždy.
Nejraději mám C++ právě proto, že tam není nevypočitatelný garbage collector a mám tak všechny alokace i dealokace paměti pod naprostou kontrolou. A kdybych už moc chtěl, tak si jej napíši a jedu dál. Nebo si udělám objekty, které vše budou řešit samy (něco jako smart pointery). To vše se zachováním superrychlosti jazyka C a s možností psát kritické smyčky třeba i v assembleru!. Tomu se prostě nic nevyrovná!
-
V duck typingu samozřejmě virtuální metody fungují, ale jsou řešeny jinak. Objekt tam s sebou nese jména svých členů a dispatch tak řeší program za běhu (prostě řeknete objektu jméno metody, kterou chcete volat, a on vám ji dodá).
No, to je pravda. Me slo spis o to, ze uz musite rict "trida ta a ta ma ty a ty metody", a tim padem jste castecne nominativni. Pritom by mohlo docela dobre strukturalne platit, ze nejaka metoda tridy zavisi na jinych metodach te tridy, takze by nebyl duvod neimplementovat tuto metodu ve vsech tridach, ktere implementuji predpoklady teto metody.
Asi jde o urcity druh dalsi urovne strukturalniho typovani, podobne jako jsou generika dalsi urovni nominativniho typovani. (A jsou s tim take spojene dalsi problemy, tezko rict, zda se to vubec vyplati resit.)
-
No, to je pravda. Me slo spis o to, ze uz musite rict "trida ta a ta ma ty a ty metody", a tim padem jste castecne nominativni. Pritom by mohlo docela dobre strukturalne platit, ze nejaka metoda tridy zavisi na jinych metodach te tridy, takze by nebyl duvod neimplementovat tuto metodu ve vsech tridach, ktere implementuji predpoklady teto metody.
Asi jde o urcity druh dalsi urovne strukturalniho typovani, podobne jako jsou generika dalsi urovni nominativniho typovani. (A jsou s tim take spojene dalsi problemy, tezko rict, zda se to vubec vyplati resit.)
Ale tohle všechny duck typing jazyky také řeší, jen jinak. Vezmete nějaký existující objekt (třeba medvěda), přidáte mu metodu pro kvákání a hned máte medvědokachnu. Pak samozřejmě lze implementovat i tovární objekty, které vytváří jiné objekty podle zadání (tak jsou implementovány třídy v Pythonu). Tyto dvě vlastnosti můžete libovolně kombinovat, takže klidně můžete vytvořit továrnu, která nechá jinou továrnu vytvořit objekt a pokud ten objekt má určité metody, tak je použije v přidané („virtuální“) metodě, a pokud je nemá, tak to implementuje jinak (nebo neimplementuje vůbec, jak chcete), v Pythonu by to bylo třeba takto:
class Kure:
def kvakni(self):
print 'Pip'
class Medved:
def __init__(self, name='grizzly'):
self.name = name
def tovarnaNaKachny(tovarna, *params, **kwparams):
import new
objekt = tovarna(*params, **kwparams)
if hasattr(objekt, 'kvakni'):
def kvakej(self):
for i in xrange(5):
self.kvakni()
objekt.kvakej = new.instancemethod(kvakej, objekt, type(objekt))
else:
def kvakej(self):
for i in xrange(5):
print 'Kvak'
objekt.kvakej = new.instancemethod(kvakej, objekt, type(objekt))
return objekt
kachnokure = tovarnaNaKachny(Kure)
kachnomedved = tovarnaNaKachny(Medved, name='brtnik')
kachnokure.kvakej()
kachnomedved.kvakej()
-
Největší nevýhodu duck typingu vidím v tom, že chyby vyplývající z použití nevhodného objektu se kolikrát mohou objevit hodne hluboko v interní kódu, aniž by na první pohled bylo zřejmé, jak je to možné. Označit objekt rozhraním přeci jen lépe označuje očekávané chování, než abych musel ke každé funkci na vnějším API psát do dokumentace, které operace má kachna umět, případně to na první úrovni složitě testovat, aby případná polokachna nepropadla až někam dovnitř, kde způsobí katastrofu.