Grafici se vykecávají (diskuse)

[freshmouse]

P.S.: A kdyby někdo navrhl jiný diskuzní systém než PunBB a překecal Honzu, tak budu rád.

[belisarivs]

Ad clanky. Uz nejake vysly nebo myslis ty zapisky v blogu? To jenom jestli jsem neco nepro.ral.

[freshmouse]

Zápisky. Ale články by měly být taky.

[xkucf03]

A kdy přibude možnost přihlašování pomocí oblíbeného OpenID?

(btw: na některých místech se tam špatně zobrazuje diakritika - jsou místo ní čtverečky, ale jinde funguje).

[freshmouse]

OpenID? Kdyby bylo na mně, tak nikdy. Jak to vidí Quetzal, nevím.

Ono to ještě není nijak nastavené. Je to prostě jen instalované... Já to nechci moc nastavovat, jelikož si to Quetzal potom stejně přenastaví podle svých potřeb.

[xkucf03]

Co je na tom řešení přístupu k různým DB tak úžasného? Chápu, že PHP nemá takové vyspělé věci jako JDBC (v Javě), ale má alespoň PDO (ukázka použití třeba tady: Ověřování uživatelů na webu)

[freshmouse]

Úžasného?

[Ladicek]

Using JDBC directly should be a sackable offence! Jediná součást standardní knihovny příšernější než JDBC je Date/Calendar

[xkucf03]

No, já taky nikomu nenavrhuji volání JDBC metod přímo z GUI (resp. prezentační vrstvy) Člověk buď použije nějaké ORM (Hibernate...) nebo si DB vrstvu napíše sám. Ale i tak jsou případy, kdy je přímé použití JDBC vhodné/potřebné: prosté přelévání dat odněkud někam (je zbytečné data převádět ještě na objekty), dolování dat, kdy pracujeme přímo s jazykem SQL, různé jednorázové věci a drobnosti...

Nicméně hlavní myšlenkou předešlého příspěvku bylo, že by se mělo používat nějaké standardní rozhraní (JDBC, ODBC, PDO...), které umožňuje (alespoň částečnou) nezávislost na konkrétním typu SŘBD. A dovoluje tak např. snadno (snadněji) vyměnit databázovou vrstvu, přejít třeba od MySQL na PostgreSQL... (i když ladění SQL dotazů se člověk stejně neunikne - kéž by tak všichni dodavatelé dodržovali standardy).

[freshmouse]

Dotaz: jsem sám, komu to přijde pomalé?

[David Ježek]

jestli to nove forum,tak me svisti velice rychle.

[freshmouse]

Zvláštní... Mně to jede hrozně pomalu a ještě se to sem tam sekne...

[freshmouse]

Už to jede jako z praku.

[freshmouse]

Grr, a teď má hosting ještě ke všemu výpadek.

[depka]

proc by mel pouzivat polymorfismus kdyz vzdy bude pouzivat pouze jeden typ databaze?

[freshmouse]

Neřekl jsem, že by měl používat polymorfismus!

[freshmouse]

Nicméně osobně bych ho asi použil -- ale rozhodně ne tak, jak to vymysleli v PunBB.

[depka]

a k cemu by ti byl? ty snad nekdy pouzivas naraz napr mysql a postrgre? nezda se ti zbytecne testovat pri kazdem volani metody jestli neni objekt potomek a nema metodu pretizenou?

[freshmouse]

Huh? jak to souvisí s pojmenováním několika tříd stejně?

[depka]

bavime se o polymorfismu, ale to je jedno....

[freshmouse]

Ano, o polymorfismu. Tam se ale stejně pojmenovávají veřejné metody, ne třídy.

[freshmouse]

$dbConnection = new $dbType;
$dbConnection->query('...');
$dbConnection->close();

Například.

[Daniel Kvasnička ml.]

Co kdyby sis nastudoval alespon zaklady OOP? http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

Polymorfismus by v tomhle pripade jednoznacne sedel. Interface databazove vrstvy a jednotlive tridy pro ruzne databaze implementujici tenhle interface, prip. jeste dedici nektere spolecne vlastnosti z nejake abstraktni tridy.

Udelat nekolik trid stejneho jmena resicich podobny problem (navic nemajicich zadneho predka!) a vybirat mezi nimi nejakym CASEm je naprosta prasarna.

[depka]

ten case je tam protoze je to config !!! chapete to? bude dedit a pretezovat bazovou tridu kdyz stejne budete celou dobu pouzivat pouze jednoho potomka ktereho si zvolite v configu podle databaze na dostupne na serveru?

[Daniel Kvasnička ml.]

bude dedit a pretezovat bazovou tridu kdyz stejne budete celou dobu pouzivat pouze jednoho potomka ktereho si zvolite v configu podle databaze na dostupne na serveru?

Samozrejme, ze ano. A budes snad ty opakovat stejny kod vicekrat i kdyz by bylo mozne ho napsat dostatecne abstraktne a jednou a psat samostatne jen kod, ktery opravdu samostatny musi byt? Odkazu te na zaklady OOP znova -- tentokrat aby sis nastudoval jaky je vyznam rozhrani. Signatura a kontrakt rozhrani rikaji programatorovi, co ma naprogramovat aby jeho pojeti dane komponenty dobre pracovalo s existujicim systemem. Konektory na ruzne databaze jsou idealnim prikladem, databazi je mnoho a je tu realna pravdepodobnost, ze fanousek nejake jine DB bude chtit na ni PunBB provozovat. A jake ma moznosti za soucasneho stavu? Studovat jak trotl existujici nijak nesladene implementace tech jejich layeru misto aby naprogramoval svuj layer proti existujicimu rozhrani a prip. vyuzil z nejake abstraktni tridy kod, ktery muze byt univerzalni (v oblasti podpory ruznych DB by se neco takoveho urcite naslo). Navic bude muset krome psani noveho layeru upravovat i onen CASE. Kdyby to bylo vyreseno pres nejaky typ reflexe (v PHP se AFAIK da instancovat trida podle jmena v retezci, da se tak myslim i odkazovat na promennou), nebyl by CASE vubec potreba.

[depka]

dekuji Ti ze me odkazujes na zaklady OOP, ale z ceske verze wikipedie se opravdu nemam co noveho naucit o OOP. Nepopiram ze tento problem silne zavani jako typicky priklad pro OOP, ale pokud budes premyslet jeste dele zjistis opak.

Predstav si ze budes psat multiplatformni tridu File, pokus by si zbrkle pouzil OOP napr takto: FileBase bude bazova trida(nebo rozhrani jestli chcete) a z te bude dedit trida FileWindows ktera bude specializovana na windows, dale FileUnix pro Unix atd.. bude se pri kazdem volani metody zbytecne testovat zda neni objekt potomkem a zda nema metodu pretizenou, zbytecne protoze za cely zbytek zivota programu od kompilace se nidky nepouzije jina specializace

anebo: napisete pouze jednu bazovou tridu bez virtualnich metod a pouzijete podmineny preklad v c/c++ pomoci #ifdef _UNIX ktery upresnite Vam urcite znamym skriptem ./configure platform=UNIX pri kompilaci?

[Daniel Kvasnička ml.]

Predstav si ze budes psat multiplatformni tridu File, pokus by si zbrkle pouzil OOP napr takto: FileBase bude bazova trida(nebo rozhrani jestli chcete) a z te bude dedit trida FileWindows ktera bude specializovana na windows, dale FileUnix pro Unix atd.. bude se pri kazdem volani metody zbytecne testovat zda neni objekt potomkem a zda nema metodu pretizenou, zbytecne protoze za cely zbytek zivota programu od kompilace se nidky nepouzije jina specializace

Ja nechapu, co mas porad s tim pretezovanim a testovanim (nehlede na to, ze nejspis myslis prekryti metody jinou implementaci v potomkovi a ne pretizeni -- pridani stejne pojmenovane metody s jinou signaturou v ramci jedne tridy). Nebude se testovat vubec nic. Na kazde platforme se podle konfigurace instancuje jina trida a na to zadne testovani neni potreba (minimalne u PHP a Javy muzu z fleku rict, ze instancovat tridu i volat na ni metody lze ze stringu, takze neni potreba jediny IF nebo CASE). A na te tride se pak budou volat metody definovane rozhranim. A kazda si to udela po svem, to me jako "klientovi" tech trid je uplne jedno, kdyz mi vrati co chci.

Delal jsem Java app, ktera mela nacitat nekolik druhu bitmap a nezavisle na typu bitmapy na ni provadet serii operaci. Kod, ktery zajistoval vyber spravne tridy pro bitmapu neobsahoval jediny podminkovy konstrukt a vzdy se vybrala ta spravna trida, vsechny dedici z AbstractBitmap. Nedokazu si predstavit to peklo kdybych pak mel operace nad abstraktnim polem obrazovych dat psat v kazde tride zvlast. Vzdyt je to prasarna! Jiste, muzes si na to vytvorit nejakou sadu nevazanych funkci a tem ta data predhodit -- ale to IMHO bije do oci, "drbani se levou rukou za pravym uchem".

Problem s tvym pohledem je ale jeste uplne jinde a uz jsem to nakousl vyse, kdyz jsem psal od ceho je rozhrani. Ty porad mluvis o behu programu, ale OO design existuje z velke casti pro programatory. Pro vetsi systemovost, jednodussi rozsiritelnost a vymenitelnost komponent. Jak uz jsem popsal -- tvuj system bez jednoticiho prvku bude znamenat peklo pro implementatory komponent, ktere se budou met stejne chovat, ale mit jinou logiku. Vazne by jsi chtel studovat nejakou tridu a zjistovat z jejiho kodu co vlastne vraci, abys mohl napsat podobnou, ale treba misto MySQL pro Oracle?

[depka]

mas pravdu pretizenim jsem myslel prekryti, zbytek naseho rozporu bude zrejme v tom ze Ty zastavas/pouzivas Javu ktera je ciste objektova a ja C++ kde se bere vetsi ohled na rychlost nez oop design(priznavam ze nevim jak v hlubinach Javy, ale v c++ kazde volani virtualni metody je zpomalene o testovani zda objekt neni potomek a nema metodu prekrytou, navic v c++ se vetsinou trida prehledne deklaruje v hlavickovem souboru a zbytek(vlastni kod metod) definuje v cpp souboru, takze neni problem z hlavickoveho souboru zjistit(studovat jak pises) co trida dela, typy metod atd.)

jinak samozrejme pro tvuj priklad z ruznymi typy obrazku je oop vhodne

[xkucf03]

A napadlo tě někdy, že přehlednost a čitelnost kódu může být znatelná, zatímco takto získané zrychlení bude zanedbatelné?

[depka]

jak kde a kdy...

[Daniel Kvasnička ml.]

Pri dnesnich cenach HW je mnohem dulezitejsi soustredit se na design. Spatny design te ve vysledku muze vyjit mnohem draz nez dobre navrzeny program, pro ktery musis koupit nejake to mego pameti navic a silnejsi procesor.

[thingie]

A v čem by to zhruba bylo lepší?

[freshmouse]

Minimálně je to přehlednější a systémovější.

[thingie]

Takto se zase nikdy netáhne zcela zbytečnej kód, který by se absolutně nikdy jinak nepoužil

[freshmouse]

A proč by se jindy měl táhnout nějaký zbytečný kód? Vždyť vždycky můžeš nějak podmínit vložení kódu (a už vůbec nemluvím o funkci __autoload()).

[thingie]

To se kruhem vracíme k otázce v čem by to bylo lepší

[freshmouse]

Vždyť říkám, přehlednější, systémovější. Soubor s názvem MySQLDriver.php obsahuje třídu MySQLDriver atd. S tím se potom dá pracovat. S pomocí __autoload() a díky něčemu jako new $dbType ještě ke všemu zkrátíš kód.

[thingie]

Jenom to nakonec v tomhle případě vyjde úplně nastejno

[freshmouse]

Délkou kódu možná ano, ale přehledností NIKDY!

[Josef Kufner]

"require neco" nebo ": neco" ? Switch je efektivnější a jednodušší. Do toho souboru stejně musíš kouknout a takle se k němu aspoň nemusíš vracet.

[Martin Tůma]

Udelat nekolik trid stejneho jmena resicich podobny problem (navic nemajicich zadneho predka!) a vybirat mezi nimi nejakym CASEm je naprosta prasarna.

Možná pro někoho, kdo odmítá jiného boha než OOP. Ale například v C se takto pomocí maker pracuje už víc jak 30 let a nikdo to za prasárnu nepovažuje...

.

[Daniel Kvasnička ml.]

Možná pro někoho, kdo odmítá jiného boha než OOP. Ale například v C se takto pomocí maker pracuje už víc jak 30 let a nikdo to za prasárnu nepovažuje...

.

Opavdu ne? Objektovy pristup neni buh, je to evolucne dany pristup, ke kteremu se doslo proste proto, ze v drtive vetsine nejlepe modeluje problemovou domenu.

[freshmouse]

Jsem ovšem nucen se ptát, proč tedy autor PunBB využívá (spíš "využívá") OOP, když to mohl udělat více než třicet roků starým způsobem?

[Grunt]

A kdy vyjde první článek ze série od GIMPu napsaný Quetzalem?

[freshmouse]

To neví ani Quetzal. Snad brzy.