abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 16:22 | Nová verze

Byla vydána verze 0.11.0 softwaru pro statistickou analýzu dat GNU PSPP (Wikipedie), svobodné alternativy k proprietárnímu softwaru IBM SPSS Statistics (Wikipedie). Vedle několika vylepšení a oprav chyb jsou řešeny také 2 bezpečnostní chyby CVE-2017-10791 a CVE-2017-10792. O týden později byla vydána verze 1.0.0 přinášející pouze aktualizaci překladů. Proč verze 1.0.0 a ne například 0.11.1? Dle vývojářů jsou důvody následující:

… více »
Ladislav Hagara | Komentářů: 0
včera 10:35 | Komunita

Na blogu Oracle se objevila zpráva o tom, že plánovaná verze Java EE 8 bude uvolněna jako open source (referenční implementace a compatibility kit). V současné době je uvolněna jen Java SE (standard edition) pod licencí GPLv2 v podobě OpenJDK (Open Java Development Kit), kterou začal v roce 2006 uvolňovat Sun.

Max | Komentářů: 3
21.8. 23:55 | IT novinky

Google na YouTube oficiálně představil Android 8.0 Oreo. Přehled novinek v příspěvku na blogu věnovaném vývojářům.

Ladislav Hagara | Komentářů: 24
21.8. 16:44 | Zajímavý článek

Po téměř 3 měsících od vydání třetího čísla publikoval Michal Špaček na svých stránkách čtvrté číslo newsletteru věnovanému bezpečnosti, bezpečnému vývoji převážně webových aplikací a bezpečnosti uživatelů. Jedná se současně o číslo poslední: "Nepíše se mi to lehce, a trvalo to, než jsem to ze sebe dostal, ale tohle je poslední newsletter v této podobě. Ani jsem ho nestihl pojmenovat a už jsem ho zabil. Nezbývá mi tolik času, abych každou událost, novinku a změnu v prohlížeči detailně popisoval tak, jak bych v newsletteru chtěl, mrzí mě to".

Ladislav Hagara | Komentářů: 2
21.8. 07:00 | Nová verze

Byla vydána diaspora* ve verzi 0.7.0.0. Jedná se o svobodný software, který slouží jako osobní webový server pro poskytování služeb sociální sítě (Wikipedie). Přehled novinek v příspěvku na blogu a na GitHubu. Sociální síť diaspora* byla před pěti lety předána komunitě.

Ladislav Hagara | Komentářů: 0
21.8. 06:00 | IT novinky

Společnost Hardkernel stojící za jednodeskovými počítači ODROID představila na YouTube minipočítač určený pro domácí cloud ODROID-HC1 vycházející z ODROID-XU4. Minipočítač s kovovou krabičkou, do které stačí vložit 2 a půl palcový disk, lze koupit za 49 dolarů. ODROID-HC1 je stohovatelný.

Ladislav Hagara | Komentářů: 39
20.8. 16:22 | Nová verze

Byl vydán DB Browser for SQLite (sqlitebrowser) ve verzi 3.10.0. Nejnovější stabilní verze této grafické nadstavby nad relačním databázovým systémem SQLite (Wikipedie) přináší například integraci s DBHub.io, tj. platformou pro sdílení SQLite databází. Podrobnosti na GitHubu.

Ladislav Hagara | Komentářů: 2
20.8. 08:00 | IT novinky

Andy Rubin, spoluzakladatel společnosti Android, jež byla v roce 2005 koupena Googlem, nyní CEO společnosti Essential Products, oznámil předprodej chytrého telefonu Essential. Telefon se začne rozesílat 1. září. Cena telefonu je 699 dolarů. Cena telefonu současně s 360° kamerou s rozlišením 4K byla stanovena na 749 dolarů. Kameru, v budoucnu i další příslušenství, lze k telefonu připojit pomocí konektoru s magnety.

Ladislav Hagara | Komentářů: 1
19.8. 13:44 | Zajímavý software

Evropská komise vydala novou verzi 1.4.0.1 svého open source v Javě naprogramovaného softwaru pro online průzkumy EUSurvey. Online dotazníky lze vytvářet na stránkách Evropské komise nebo si lze software stáhnout (zip a war) a nainstalovat lokálně. Zdrojové kódy jsou k dispozici pod licencí EUPL (European Union Public Licence).

Ladislav Hagara | Komentářů: 0
18.8. 23:55 | Komunita

Ubuntu 17.10 (Artful Aardvark) bude ve výchozím stavu zobrazovat Dok (Launcher). Jedná se o rozšíření GNOME Shellu Ubuntu Dock. To bylo forknuto z rozšíření Dash to Dock. Ukázka na YouTube [reddit].

Ladislav Hagara | Komentářů: 8
Těžíte nějakou kryptoměnu?
 (5%)
 (2%)
 (18%)
 (76%)
Celkem 374 hlasů
 Komentářů: 21, poslední 13.8. 09:57
    Rozcestník

    Dotaz: "Přetížení" classy

    24.2.2011 02:29 camel1cz | skóre: 23
    "Přetížení" classy
    Přečteno: 347×
    Zdravím všechny a PHP guru zvlášť :-P

    Úvodem se omlouvám za slohovku.

    Intro: Vyvíjím v PHP aplikaci, která je několikrát naimplementována. Jde o vždy stejný kód "jádra" (udržovaný bugfixy) a implementační úpravy. Teď je to řešeno ošklivým ofejkem.

    Co bych chtěl je následující:

    Situace: mám např. třídu A v metodou A::X v jádru aplikace (tuto metodu používá celý zbytek aplikace),

    Problém: vymyslím si, že v jedné implementaci chci aby metoda A::X vracela jiný výsledek než v ostatních

    A teď jsem u té otázky, jak to udělat?

    Dneska sem nad tím dumal a vymyslel 2 způsoby (v obou jsem se zasekl)

    A) udělám kopii třídy do jiného adresáře, upravím jí a patchnu autoloader, aby nahrál patchovanou verzi (tohle je sice OK, ale ztratím centrální bugfixy - všechny opravy budu muset mergovat do upravených souborů, což je fatální)

    B) udělám pro upravenou třídu namespace, zdědím z globální třídy \A do třídy NS\A a upravím jen metodu A::X - hurá! Jenže: při vytváření instance ve zbytku aplikace volám: $a = new A(); Což je na tvrdo globální namespace - zkoušel sem čachrovat s use NS; atd. ale bez úspěchu :-(

    Jsem v koncích... má někdo nápad? Uniká mi něco?

    Díky moc za radu/postrčení!

    Odpovědi

    24.2.2011 10:23 jehovista
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    Nejsem PHPkar, ale neresi tohle factory pattern? Metody das do interface a jaka se pouzije implementace bude resit factory.
    24.2.2011 11:40 camel1cz | skóre: 23
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    Ano, máš pravdu - tohle je řešení.

    Fungovalo by:
    $trida = Model::factory('JmenoTridy');
    
    A v té statické metodě factory ošéfovat co je třeba.

    V krajním případě tohle použiju, děkuju za návrh!

    Nenapadá někoho něco ještě lepšího? Nejraději bych psal:
    $trida = new JmenoTridy();
    
    Ale zdá se, že tohle nemá řešení :-(
    24.2.2011 18:36 jehovista
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    Nevim, proc chces zrovna tohle, ale to prece muzes vyresit tim autoloaderem a dedicnosti(v te konkretni tride bude implementovano jen to, co se lisi).
    24.2.2011 23:38 camel1cz | skóre: 23
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    Díky za reakci!

    Mohl bys být konkrétnější?

    Důvody, proč a co chci jsem myslím napsal v prvním postu...

    Ten návrh "autoloader" + "dědění" jsem rovněž zmiňoval v prvním postu - včetně věcí, které nejdou resp. neumím.

    Ještě jednou shrnu problém s dědičností a autoloaderem:

    Fakt: nemůžu dědit třídu do sebe sama (class A extends A)

    Požadavky:

    1) změny ve třídě A mají být realizovány dědičností

    2) konstrukt new A má vytvořit instanci správné třídy (potomka se změnou popř. předka, pokud potomek neexistuje)

    A teď:

    Protože Fakt, musím pro zdědění použít namespace. Tedy:
    namespace NS;
    class A extends \A {
    }
    
    Pro požadavek 2) zavolám v jádře:
    ...
    $a = new A();
    ...
    
    Interpret nahraje třídu z jádra... donutit na jinou ho dokážu pouze konstruktem uses, ale pak nebude fungovat varianta, kdy nová třída neexistuje.

    Opravdu si začínám myslet, že to prostě nemá řešení a budu muset udělat nějaký workaround typu factoring...

    Díky
    25.2.2011 06:35 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    vymyslím si, že v jedné implementaci chci aby metoda A::X vracela jiný výsledek

    Jak moc jiný?
    při vytváření instance ve zbytku aplikace volám: $a = new A();

    Proč to nemůžete ve zbytku aplikace volat jinak?
    In Ada the typical infinite loop would normally be terminated by detonation.
    25.2.2011 14:23 camel1cz | skóre: 23
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    vymyslím si, že v jedné implementaci chci aby metoda A::X vracela jiný výsledek

    Jak moc jiný?

    Typicky jde o customizace nějaké obecné metody. Např. metoda standardně vypisuje všechny soubory v adresáři, ale já chci v jedné implementaci, aby nevypisovala skryté (.*) - tedy zdědím, předeklaruju tu metodu, ta zavolá původní metodu a profiltruje výsledek na .*

    při vytváření instance ve zbytku aplikace volám: $a = new A();

    Proč to nemůžete ve zbytku aplikace volat jinak?

    Ne včechna užití té třídy jsou napsaná mnou - využívám framework.

    Před chvílí sem s kolegou vykoumal řešení, které mi příjde akceptovatelné: core třída i ta implementační budou mít jméno s nějakým prefixem a v autoloaderu zařídím vedle require příslušného souboru také vytvoření aliasu třídy na "bezprefixový zápis". Např.

    // deklaruju core v souboru $core_prefix/A.php
    class Core_A {};
    
    // deklaruju změněnou třídu v souboru $implementacni_prefix/A.php
    class Implementace_A extends Core_A {}
    
    // v běžném kódu používám
    $a = new A();
    
    // popř.
    class B extends A {}
    
    // v autoloaderu podle jména třídy najdu správný include
    require_once($classname);
    class_alias($prefix.$classname, $classname);
    
    Nic lepšího asi nevymyslím :-)
    25.2.2011 17:41 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    Např. metoda standardně vypisuje všechny soubory v adresáři, ale já chci v jedné implementaci, aby nevypisovala skryté (.*) - tedy zdědím, předeklaruju tu metodu, ta zavolá původní metodu a profiltruje výsledek na .*
    Není jednodušší nechat tu původní metodu bejt a udělat si ten filtr bokem?
    $fileFinder = new FileFinder();
    $filter = new NoHiddenFilesFilter($fileFinder->getFiles());
    $files = $filter->getFiltered();
    

    Nebo použít dekorátor
    $baseFileFinder = new FileFinder();
    $noHiddenFilesFinder = new NoHiddenFilesFinder($fileFinder);
    $files = $noHiddenFilesFinder->getFiles();
    
    V obou případech nemusíte na původní třídu ani hrábnout.
    In Ada the typical infinite loop would normally be terminated by detonation.
    25.2.2011 18:32 camel1cz | skóre: 23
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    Ano, tohle je řešení. Jestli to správně chápu, navrhujete vlastně zadefinovat systém pluginů, které umožní měnit předem vymezené vlastnosti aplikace.

    Mým cílem je aplikace, která něco umí a je možné ji co nejširším způsobem a s co nejmenčí redundancí kódu upravovat.

    Rozvedu náš příklad do reálnější podoby. Následuje struktura volání aplikace "webový manažer souborů":
    class aplikace -(1)-> class fileFinder -(2)-> class htmlRenderer
    
    Rozhodnu se, že chci upravit fileFinder diskutovaným způsobem. A mám následující možnosti:

    1) aplikace musí být naprogramovaná tak, že umí nahradit třídu fileFinder jinou (např. v konfiguráku bude jméno třídy)

    2) fileFinder musí mít rozhraní pro aplikování vybraných operací s možností ovlivnit výsledné chování - tedy fileFinder musí mít rozhraní pro pluginy a v runtime někde uloženou jejich konfiguraci - to je Vaše řešení?

    3) do místa (1) vložím vlastní kód, který udělá co bude potřebovat, využije třeba alternativní třídu pro fileFinder, ale pak musí zajistit volání htmlRendereru v kroku (2) sám

    4) řešení co sem navrhl odpoledne - tedy nějak elegantně zařídím, aby celá aplikace používala místo třídy fileFinder úplně jinou třídu (potomka původní nebo implementující stejný interface)

    Varianta 1) a 2) je OK, ale vyžaduje předem vyspecifikované podporované změny chování aplikace. Každé rozšíření těchto možností znamená netriviální úpravu aplikace. Navíc tato řešení neumí měnit předky používaných metod. Neumí se "vklínit" do posloupnosti dědění, a nahradit pouze jeden článek. Takto je možné pouze v libovolném místě řetěz dědění přetnout a pak znovu doimplementovat až do finálních tříd (tedy redundance kódu a druhotně podobný nešvar jako má 3)

    Varianta 3) se mi hrubě nelíbí. Vyžaduje dost redundantní práce.

    Co říkáte na Variantu 4)?
    25.2.2011 20:26 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    class aplikace -(1)-> class fileFinder -(2)-> class htmlRenderer
    Pokud je tohle posloupnost volání, tak to je instance něčeho co pracovně nazývám architektura trubka nebo štafeta. Tam máte natvrdo zadrátovánou tu šipku č. 2 a nemůžete s tím nic udělat. To je váš hlavní problém, kterého se potřebujete zbavit.

    Pokud byste volání předělal takto:
        class aplikace -> class fileFinder 
                       <- $files                                        
                       -> class htmlRenderer
    
    Tak s tím můžete pak dělat co chcete.
    varianta (A): nezávisle fungující Finder a Filter
    
        class aplikace -> class fileFinder 
                       <- $files            
                       -> class fileFilter
                       <- $filteredFiles
                       -> class htmlRenderer
    
    nebo
    varianta (B): Dědění nebo lépe Dekorátor
    
        class aplikace -> class filteredFileFinder 
                                                   -> class fileFinder
                                                   <- $files
                       <- $filteredFiles
                       -> class htmlRenderer
    
    Mým cílem je aplikace, která něco umí a je možné ji co nejširším způsobem a s co nejmenčí redundancí kódu upravovat.
    Můžete tohle aplikovat na stávající požadavky, nebo ty, které s nějakou rozumnou pravděpodobností očekáváte, ale nemůžete udělat univerzální stroj.
    1) aplikace musí být naprogramovaná tak, že umí nahradit třídu fileFinder jinou (např. v konfiguráku bude jméno třídy)

    To je klasický příklad použití vzoru Factory.
    varianta (C): Factory
    
    $className = getConfigOption("fileFinderClass");
    $factory = new FileFinderFactory();
    $fileFinder = $factory->createFileFinder($className);
    
    2) fileFinder musí mít rozhraní pro aplikování vybraných operací s možností ovlivnit výsledné chování - tedy fileFinder musí mít rozhraní pro pluginy a v runtime někde uloženou jejich konfiguraci - to je Vaše řešení?
    To by byl následující kód:
    varianta (D): Filter jako plugin funkcionalita Finderu
    
    $filter = new WhateverFilter();
    $fileFinder = new FileFinder($filter);
    $files = $fileFinder->getFiles();
    
    To je ještě další varianta, kterou můžete použít.
    3) do místa (1) vložím vlastní kód, který udělá co bude potřebovat, využije třeba alternativní třídu pro fileFinder, ale pak musí zajistit volání htmlRendereru v kroku (2) sám
    To je něco čemu byste se měl vyhnout - fileFinder by měl výsledek vracet a ne štafetově předávat a mělo by mu být úplně jedno kdo ho zavolal a komu ten výsledek vrátí. Pak nebude problém s vložením kódu.
    4) řešení co sem navrhl odpoledne - tedy nějak elegantně zařídím, aby celá aplikace používala místo třídy fileFinder úplně jinou třídu (potomka původní nebo implementující stejný interface)

    Tím pouze používáte pneumatické kladivo tam kde stačí trochu ťuknout hřebíček.
    Neumí se "vklínit" do posloupnosti dědění, a nahradit pouze jeden článek.
    Proto se dědění moc nepoužívá - vytváří vazby moc natvrdo. Pokud tam potřebujete něco vklínit, je lepší použít volnější vazby, viz příklady.

    V kódu nahoře jsem označil varianty ABCD, chtěl bych shrnout výhody a nevýhody každé:

    A) (nezávislé třídy Finder a Filter) nejobecnější možnost, kde ani jedna třída neví o jiné - můžete kombinovat všechno se vším a udělat téměř jakékoliv chování.

    B) (Filter jako dekorátor nad Finderem) něco jako dědění, můžete před a po volání základního Finderu provést libovolnou modifikaci a vrátit výsledek ve stejném formátu. Oproti dědění můžete ty modifikace libovolně nabalovat na sebe a to i v době běhu aplikace.

    C) (Factory) výroba různých komponent (Finderů, Filtrů, ...) je schována na centrální místo, a případně konfigurovatelná uživatelem. Řekl bych, že to je spíš doplňková záležitost k ostatním variantám.

    D) (Plugin Filter) implicitně předpokládáte že se nějaký filtr použít musí, byť třeba prázdný. Hodí se, pokud je hodně jednoduchých Filtrů ale třeba jen jeden Finder. Místo jednoho filtru můžete třeba pluginovat pole filtrů atd.

    In Ada the typical infinite loop would normally be terminated by detonation.
    25.2.2011 21:30 camel1cz | skóre: 23
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    Moc hezké shrnutí! Děkuju za čas!

    ...nejspíš tedy půjdu cestou "pneumatického kladiva", ono mé zadání má dost specifik, která přesahují rámec diskuze na netu a přechází spíš do ranku diskuzí u piva :-D Ale každopádně sem si moc rád přečetl a ujasnil výše zmíněné varianty.

    A) je fajn, ale až příliš volná - přecijen chci nastavit nějaké mantinely (co má aplikace z byznys pohledu umět)

    B) se mi hodně líbí a tak nějak sedí mému stylu

    C) souhlasím, dobrá věc, ale dělat tak všechny třídy v celé aplikaci je IMO nesmysl (a ani to nejde)

    D) vnímám jako nejsprávnější, ale (alfa) sem na to línej, (beta) těžko se to mění a projekt žije a vyvíjí se, ...

    Hlavní motivací pro pneumatické kladivo je nedůvěra v zákazníky :-D ...kdybych vymyslel variantu laserové dělo, s chutí kladivo zahodím :-D
    26.2.2011 05:43 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    ...nejspíš tedy půjdu cestou "pneumatického kladiva"
    Akorát že, i když tu třídu nahradíte v runtime nebo nějakým hackem s include, tak nevyřešíte podstatu problému a to sice, že budete mít pořád na krku tu odpornou povinnost v náhradní třídě volat ten htmlRenderer.
    C) souhlasím, dobrá věc, ale dělat tak všechny třídy v celé aplikaci je IMO nesmysl (a ani to nejde)

    Jsou na to frameworky.
    In Ada the typical infinite loop would normally be terminated by detonation.
    26.2.2011 14:39 camel1cz | skóre: 23
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    ...nejspíš tedy půjdu cestou "pneumatického kladiva"
    Akorát že, i když tu třídu nahradíte v runtime nebo nějakým hackem s include, tak nevyřešíte podstatu problému a to sice, že budete mít pořád na krku tu odpornou povinnost v náhradní třídě volat ten htmlRenderer.
    Myslím, že ne... resp. šikovným designem metod docílím toho, že bude nějaká "worker" metoda, kterou můžu měnit a další metody zařídí začlenění do systému - těch se dotýkat nebudu (moct). Navíc je tak velice elegantně vyřešeno automatické používání nové funkčnosti v celém systému.
    C) souhlasím, dobrá věc, ale dělat tak všechny třídy v celé aplikaci je IMO nesmysl (a ani to nejde)

    Jsou na to frameworky.
    Jako např? ...jak řeší dědění z těchto tříd? Nechci už moc prudit, odkaz na doc úplně stačí :-) Díky!
    26.2.2011 15:27 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: "Přetížení" classy
    šikovným designem metod docílím toho, že bude nějaká "worker" metoda, kterou můžu měnit
    Super, to zní dobře.
    Jako např? ...jak řeší dědění z těchto tříd? Nechci už moc prudit, odkaz na doc úplně stačí :-) Díky!

    Zkuste se podívat/inspirovat např. http://substrate-php.org/ případně existuje asi kopa alternativ... hledejte "php ioc framework".

    Dědění (implementace) bych doporučil na nějaký čas úplně vynechat a zkusit to řešit přes ten "šikovný design"...
    In Ada the typical infinite loop would normally be terminated by detonation.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.