Přejít k navigační liště

Zdroják » JavaScript » Třídy, dědičnost a OOP v Javascriptu – III

Třídy, dědičnost a OOP v Javascriptu – III

V předchozích článcích na téma objektově orientovaného programování v Javascriptu jsme probrali způsoby, jak k objektům v JS lze přistupovat a řekli jsme si, jaký způsob je přijatelný a proti kterým lze mít výhrady. Na závěr se podíváme, jak se k problému staví ostatní javascriptové knihovny a jak řešit OOP efektivně.

Minule jsme si probrali, jak se v Javascriptu vytváří třídy, i jak funguje dědičnost. Dnes si ukážeme další techniky a to, jak se k problému staví různé knihovny.

Každá Javascriptová knihovna (krom jQuery) se snaží nabídnout nějakou stručnější, jednodušší definici třídy a vyjádření dědičnosti, což je v pořádku. BasePrototy­peJS a Mootool­s jdou ještě dál, a snaží se „usnadnit“ volání přepsané metody, což je dle mého skromného soudu zbytečné a omezující. Ukázali jsme si, že volat lze libovolnou metodu, tak funguje Javascript. Přesto si Dean Edwards kdysi dávno řekl, že to nestačí. Jeho řešení spočívá v tom, že každou metodu obalí další metodou, v jejímž closure je schovaná reference na přepsanou metodu, která se před samotným voláním zabalené metody dočasně nastaví na this, pod vlastnost _super. Tuto techniku převzaly výše zmíněné knihovny. Já ji však považuji za zbytečnou, a proto se o ní nebudu dále zmiňovat. Pokud chcete více informací, docela pěkný článek lze nalézt na: http://we­breflection.blog­spot.com/2010/02­/javascript-override-patterns.html 

Nešla by definice třídy zapsat lépe?

Jak je vidět v ukázce z minulého dílu, zápis není zrovna stručný. Je pln provozního kódu. Třídy vytváříme impe­rativně, což není zrovna hezké. Šlo by to deklarativ­něji? Ano, elegantně a snadno. Následující příklad už vypadá lépe.

// třída Person
var Person = $class({

    constructor: function(name) {
        this.name = name;
    },

    getName: function() {
        return this.name;
    }

});

// třída Employee
var Employee = $class({

    Extends: Person,

    constructor: function(name, salary) {
        Person.call(this, name);
        this.salary = salary;
    },

    // přepisujeme metodu z třídy Person
    getName: function() {
        var name = Employee._superClass.getName.call(this);
        return name + ' (zaměstnanec)';
    },

    getSalary: function() {
        return this.salary;
    }

});

Příklad: http://jsfiddle­.net/hJbPr/

Princip tříd a dědičnosti je stejný, jako ve dříve zmíněném kompletním příkladě, ale syntax je stručnější a přehlednější díky funkci $class.

Na scénu přichází $class

$class je tovární funkce a syntax sugar pro deklaraci tříd. Napsal jsem ji pro tento článek, i když implementace vychází z mé vlastní knihovny. Aby předchozí příklad fungoval, může $class vypadat třeba takto:

// pozor, toto je pouze návrh
var $class = function(definition) {
    var constructor = definition.constructor; 
    var parent = definition.Extends;
    if (parent) {
        var F = function() { };
        constructor._superClass = F.prototype = parent.prototype;
        constructor.prototype = new F();
    }
    for (var key in definition) {
        constructor.prototype[key] = definition[key];
    }
    constructor.prototype.constructor = constructor;
    return constructor;
};

Tím bychom měli vyřešený elegantní zápis třídy. Pokud z nějaké třídy dědíme, použijeme vlastnost s názvem Extends. Zatím jsme probrali pouze třídy a dědičnost. Ať zvedne ruku ten, kdo myslí, že dědičnosti je skvělým nástrojem, jak se vyhnout opakovanému kódu. – Tak ti, co si to myslí, si to myslí špatně! Třídy rozhodně nedědíme proto, abychom se vyhnuli opakovanému kódu; to bychom zvládli i bez tříd. Třídy dědíme, protože chceme vyjádřit vztah, jaký mezi sebou mají. Bázová třída reprezentuje nějaký doménový problém. Děděním, tedy vytvářením potomků, problém upřesňujeme.

Zbožštění dědičnosti je častou chybou mnoha programátorů. V jednom svém bývalém zaměstnání jsem viděl projekt, jehož zadání znělo: „Vezmi hodnotu z formulářového políčka, pošli ji na webovou službu, a XML výsledky, co se ti vrátí, vypiš v HTML tabulce.“ Projekt měl dobře přes dvacet tisíc řádků a vyznat se v něm bylo peklo, protože valná většina kódu byly prázdné definice tříd, které ve skutečnosti nic nedělaly, jen existovaly. 

Daleko častější technikou objektově orientovaného programování je agregace. Když začneme psát program, nehledáme co by se kde dalo podědit, ale spíše vytváříme vlastní třídu, která agreguje třídy jiné. Kdy použít dědičnost, a kdy agregaci, vám neprozradím, protože tento článek není o problematice objektového návrhu, ale o jeho implementaci v Javascriptu. Pokud vás problém dědičnost versus agregace zaujal, můžete začít třeba zde: http://s­tackoverflow.com/qu­estions/269496/in­heritance-vs-aggregation

Daniel Steigerwald nabízí školení a konzultace JavaScriptu. Bližší informace zájemci naleznou na daniel.steiger­wald.cz

Mixování

Dynamické jazyky nám nabízejí pokročilejší formu agregace, mixování. Už jsme si ukázali, jak lze třídě přepsat (nebo přidat) metodu.

Person.prototy­pe.serialize = function() {};

Takové úpravy však nejsou pěkné. Kód plný „záplatování a vylepšování“ je jistou poukázkou na pobytovou prohlídku psychiatrické léčebny. Následující příklad už vypadá lépe:

var Serializable = {
    serialize: function() {}
};

// imperativní zápis
Person.mixin(Serializable);

// deklarativní zápis
var Person = $class({
    Mixins: Serializable
});

Mix je samostatným objektem, lze jej tedy snadno sdílet mezi třídami, i testovat. Mixy použijeme vždy, když chceme rozšířit třídu o nějakou funkcionalitu, která není formou její specializace. Mixování se v Javascriptu považuje za náhradu vícená­sobné dědičnosti. Mixy si lze také představit jako rozhraní s implementovanými metodami nebo abstraktní tří­du.

Ve skutečnosti je mix prostý statický objekt, jehož vlastnosti se při mixování nakopírují do vlastnosti prototype. Proč objekt a ne třída? Nechceme, aby bylo možné z mixů vytvářet instance. Už víme, že vztah mezi třídou a instancí je v Javascriptu „živý“ (změníme prototype, a změna se projeví i na všech instancích). Nechceme však ani naznačovat, že něco takového je s mixy možné. Javascript nepodporuje vícenásobnou dědičnost, mix sám o sobě nevstupuje do řetězu prototypové dědičnosti, instanceof operátor mixy ignoruje.

Stejně jako pro dědičnost, ani pro mixy nemá Javascript klíčové slovo, proto si jej implementujeme sami. Ve funkci $class, jsme pro určení bázové třídy použili vlastnost Exten­ds.Vezmeme to jako úzus (PascalCase), a nadefinujeme si další vlastnost: Mi­xins. Aby nám $class moc nenakynula, trochu ji zrefaktorujeme. Implementace $class s podporou mixování vypadá pak takto:

Kompletní příklad

var $class = function(def) {
    // pokud není konstruktor definován, použijeme nový (nechceme použít zděděný)
    var constructor = def.hasOwnProperty('constructor') ? def.constructor : function() { };
    // proces vytváření třídy rozdělíme do kroků
    for (var name in $class.Initializers) {
        $class.Initializers[name].call(constructor, def[name], def);
    }
    return constructor;
};

$class.Initializers = {
    Extends: function(parent) {
        if (parent) {
            var F = function() { };
            this._superClass = F.prototype = parent.prototype;
            this.prototype = new F;
        }
    },

    Mixins: function(mixins, def) {
        // kostruktoru přidáme metodu mixin
        this.mixin = function(mixin) {
            for (var key in mixin) {
                if (key in $class.Initializers) continue;
                this.prototype[key] = mixin[key];
            }
            this.prototype.constructor = this;
        };
        // a přidanou metodu hned využijeme pro rozšíření prototype
        var objects = [def].concat(mixins || []);
        for (var i = 0, l = objects.length; i < l; i++) {
            this.mixin(objects[i]);
        }
    }
};

// mix Serializable

var Serializable = {
    serialize: function() {
        // sem patří nějaká forma serializace, např. JSON.stringify(this);
        return 'serialized';
    }
};

// třída Person
var Person = $class({

    Mixins: Serializable,

    constructor: function(name) {
        this.name = name;
    },

    getName: function() {
        return this.name;
    }

});

// třída Employee
var Employee = $class({

    Extends: Person,

    constructor: function(name, salary) {
        Person.call(this, name);
        this.salary = salary;
    },

    // přepisujeme metodu z třídy Person
    getName: function() {
        var name = Employee._superClass.getName.call(this);
        return name + ' (zaměstnanec)';
    },

    getSalary: function() {
        return this.salary;
    }

});

// Nyní kód otestujeme

// vytvoříme instanci
var joe = new Employee('Joe', 1000);

// všechny tyto testy musí projít
alert([
    joe.serialize() == 'serialized',

    joe.getName() == 'Joe (zaměstnanec)',
    joe.getSalary() == 1000,
    joe instanceof Person,
    joe instanceof Employee,
    typeof Employee == 'function',
    typeof joe == 'object',
    joe.constructor == Employee,
    Employee._superClass == Person.prototype
]); 

Ukázka: http://jsfiddle­.net/me9jZ/

Příklad ukazuje jednoduchý mix Serializable. V praxi se mixování používá pro přidávání složitější funkcionality. Například Yahoo knihovna YUI3, kde se mimochodem používá termín augmentation, používá mixování pro implementaci událostí

Javascript DSL

V průběhu seriálu jsem několikrát použil obrat „chybí klíčové slovo“. Někoho by tak mohlo napadnout, že vlastně Javascript ohýbáme, a že to není pěkné. Situace se hned vyjasní, když si uvědomíme, že vlastně neděláme nic jiného, než vytváříme doménově specifický jazyk. Právě proto, že Javascript je pružný a dynamický jazyk, je snadné vytvořit konstrukty, které se mu do vínku nedostaly, prostě proto, že o nich autor Javascriptu neměl ponětí.

Závěr

Zdaleka jsme nevyčerpali téma, článek by mohl pokračovat dále. V klobouku zůstalo ještě pár zajímavých témat, například: návrhové vzory, AOP, reaktivní extenze, další rozšiřování $class… Ale v nejlepším se prý má přestat. Bude-li zájem, další díly vás rozhodně neminou. Pokud máte doplňující otázky nebo připomínky, použijte diskuzi pod článkem, nebo si přijďte popovídat sedmého dubna na IDF 2010. Budu se těšit.

Nepřehlédněte!

Autor článku Daniel Steigerwald vystoupí s přednáškou na téma Třídy, dědičnost a OOP v Javascriptu na letošní konferenci Internet Developer Forum 2010. Přijďte si jej (a samosebou i další přednášející) poslechnout a zeptat se jich na to, co vás zajímá, ve středu 7. dubna do Národní technické knihovny (registrace nutná).

Komentáře

Subscribe
Upozornit na
guest
38 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
xy

me by zajimalo, jak se autor dobral k takovemu napadu mam na mysli to $class… nejak se mi nechce verit ze clovek proste jen tak sam od sebe vymysli, protoze me by to asi jen tak nenapadlo… je to teda inspirace ve forme cteni zdrojaku YUI? mimochodem pouzivat za kazdou cenu ten $ to je fakt trosku matouci… clovek kdyz to vidi poprvy tak si mysli ze jde o jQuery a ono ne… chapu ze ten dolar je dneska ve zdrojacich JS v mode asi jako mezi lidma facebook… ale zkusme to bez toho dolaru ne? kdyz jde o ne-Jquery vlastni reseni :P

xy

heh, hm dik za odpoved… jinak jeste by me zajimalo, kdyz takhle umis JS, jestli jsi na tom stejne s dalsim programovacim jazykem treba PHP, popripade se znalosti SQL atd, nebo v tom ostatnim trochu plaves… podle myho totiz, tech vedomosti ktery clovek muze mit jenom o PHP (a dnes uz i o JS) je tolik, ze je asi nemozny znat vse

Oldis

To co je zde uvedeno v serialu, se da velmi snadno najit, samozrejme ne cesky ale anglicky, nejjednodussi je asi najit si stranky Daglese Croforda, popripade jeho prednasku. JS je objektovy jazyk, a pokud clovek umi programovat a zvladne oop, tj. zvlada alnayzu i kodovani, tak je potom jazyk jen otazkou syntaxe, moznosti a api, osobne umim krome c++, i js, javu, php, mysql, actionscript, a jeste par dalsich jazyku, ale ty pouzivam jen zridka a nektere sem nepouzil uz leta.
Tento serial je velmi dobry, spojuje do jednoho celku, informace ktere se daji najit jen osamocene, a spojuje je velmi dobre, uvadi proc se pro urcitou funkcnost pouziva dany konstrukt tak a i proc nepouzivat jiny.

xy

jasne, souhlasim s tim, ze programovaci jazyk je otazkou syntaxe… tj, pokud dnes delam v PHP, nemel by byt teoreticky problem pro me prejit na C#, na Visual Basic, Python nebo cokoliv jineho… protoze vse je jen programovaci jazyk… jenze, jsem skepticky vuci tomu, ze je nekdo odbornikem na vse… ze nekdo rika (treba jako ty :) ), ze umis c++, js, javu, php… podle me se da znat vse povrchne, ale ne do hloubky.. myslim si, ze clovek tak nak umi jen to, co pouziva denne… kdyz nebudu denne pouzivat JS, tak 90 procent toho z clanku zapomenu… uz treba za 30 – 60 dni.

Michal Augustýn

Programovací jazyk je sice otázkou syntaxe, ale aby byl člověk schopen něco rozumného vyplodit, potřebuje znát taky knihovny, které jsou s daným jazykem/prostředím spjaté. A tam už učení nejde tak rychle a vyžaduje to zkušenost…

Oldis

ano jazyk je otazkou syntaxe, ale uz ne programovani, pokud nekdo dela v php, teoreticky muze prejit na c++ nebo c#, prakticky zalezi na tom jak pracoval v php, v php jde delat proceduralne i pomerne striktne objektove. treba python mi vylozene nesedi, az moc mi pripomina paskal. Odbornik samozrejme clovek nemuze byt na vse, jen na c++ je nekolik ruzne orientovanych platforem, ktere sice maji zakladni knihovny stejne, ale dal se uz deli dle frame worku. Pak je rozdil v tom vymyslet pristup k reseni problemu s navrhovym vzorem v danem jazyce a nebo si o nem uz jen precist a nabyte znalosti pouzivat. pristup vsech oop jazyku je vesmes stejny, klicova slova take, lehce se lisi ve vlastnostech, proto uz je spis dulezitejsi, umet analyzovat problem, a predstavit si oop reseni, a pripadne vedet kde najdu informace o tom jak resit nebo obejit nedostatek daneho jazyka, viz dedicnost v js, jave v php, as3 a podobne. co se tyce znalosti c++, tak napriklad oop v nem zvladam bez problemu, knihovny zanm zakladni, pak zlehka mfc, ale protoze me mfc omezovalo, tak sem presel na win32 a pak sem se podival i na directx. to ovsem bylo pred osmy lety, a v c++ sem denodenne delal asi tak pet let. v jave si obcas napisu nejakou utilitu, typicky kdyz potrebuju prevest nejaka data a potrebuji k tomu jednoduce gui. osobne ji nemam moc rad. pred 16lety sem delal s qbasicem, pak s paskalem, pak s c++, pak s win basicem, pak s visual c++, a ted v php a mysql.

Michal Augustýn

Nějak jste asi nepochopil, co jsem chtěl říct předchozím příspěvkem.

Naučit se syntaxi nového jazyka opravdu nedělá průměrnému programátory velký problém. V praxi je ale pro rozumnou produktivitu a kvalitu kódu důležité, aby člověk znal relevantní knihovny a best practices nové platformy. A tahle zkušenost je často mezi jazyky/platformami nepřenosná, takže migrace na nový jazyk pro praktické použití není vždy zas tak hladká…

Oldis

no snazil sem se rict ze obecne porozumeni je dulezitejsi nez konkretni znalost syntaxe, podobne jako v matematice, je dulezitejsi umet z jednoho vztahu odvodit ten ktery potrebuju nez znat nazpamet ten konkretni. a pak ze je dulezitejsi vedet kde informace hledat nez si je opet nazpamet pamatovat. pak existuji napriklad navrhove vzory, ktere jsou obecne a pro jednotlive jazyky existuje vzor implementace. migrace vetsinou neni hladka, pro me nebyla nikdy, ikdyz jsou svele vijimky. Shrnu to, stejne jako jsou absolventi vysokoskolske matematiky dvojiho druhu, prvni se vse nauci nazpamet a druhzi krteri ji skutecne porozumi, tak je tomu i mezi programatory. jsou jedni kteri si pamatuji nazpamet desitky/stovky reseni a jsou druzi kteri porozumi, pro prvni je prechod najinou platformu/jazyk osobni tragedii, pro druhe prilezitost k rozvoji, a podle toho dopadne i vysledek.

Martin Soušek

Je zajímavé, že velkou oblibu si získala knihovna jquery, která nemá žádné objektové vychytávky, její pluginy jsou šílené bastly a pokus o widgety jquery ui je nehorázný humus.

A relativné krásné mootools nebo google closure se nepoužívají, protože když jsem postaven před projekt, jehož velkou část by vyřešily existující jquery pluginy, tak radši volím jquery, než abych to všechno psal sám za podpory krásné knihovny.

Ped

Ja bych rekl tim ze spousta lidi co pouziva cizi js knihovny js vubec neovlada. Proste najde knihovnu ktera udela to co potrebuji a pouziji ji, vzhledem k ohebnosti js to vetsinou dela i to co chteli, a dokonce dost casto to ani nedela nic co by nechteli. (alespon ja jsem jiz js nekolikrat pouzil, ackoli o nem nic nevim (krome toho ze ma syntax dostatecne C-like, abych si stazeny zdrojak pripadne trochu ohnul pro sve potreby) … az diky teto serii clanku vidim jak moc je odlisny a jak moc ho neznam).

Proto proste humus jquery jim zustane naprosto skryty a netusi o nem. :)
Tim nerikam ze je to dobre, jenom popisuji jak dnes vznika SW … se neco nekde veme, trochu se to slepi a kdyz to vypada funkcne, tak se to proda, takova je doba. :)

Bauglir

Jenže od toho knihovny máme, že. Máme je od toho,a by dělali, co chceme, nebudeme vynalézat znovu kolo.
Váš popis, jak vzniká SW je celkem přesný, jenže nezbytný… kam až byste chtěl jít? Zkuste si představit programování dektopových aplikací, jak byste řešil problémy bez použití systémových knihoven (o kterých nevíte naprosto nic… Kdo přečetl zdrojáky všech linuxových knihoven, které kdy použil, ať se přihlásí, u Win tu šanci ani nedostanete). Zkusil jste si někdy například ve Win vytvořit primitivní formuláříček jenom pomocí Windows API? Různé component library (widgety) rozhodně usnadní práci… Navíc, co je Win32Api jiného, než sada dll (knihovny)…
Neodběhl jsem jen od JS tak pro nic za nic, protože i pro JS platí naprosto to stejné co jiné jazyky: knihovny ušetří spoustu práce, jen musíte najít… Věřte, že i pro jiné jazyky existuje spousta nesmyslných knihoven.

Problém JS není v tom, že spousta lidí, co JS knihovny používá vůbec JS neovládá, problém je v tom, že spousta lidí, kteří JS používá JS vůbec neovládá (knihovny neknihovny). Pascal, C, C++, C#, Java… všechno se řádně učí, studuje.. JS nikoliv, přesto, že by se nad tím rok strávit dal…
A kdo nestuduje (nemyslím nutně ve škole) ani ostatní jazyky, píše jako prase také, jenom to v binárce není vidět :)

Ped

Ano, knihovny jsou v podstate od toho, ale je dobre mit alespon zakladni prehled jak dana knihovna funguje (jak naklada se zdroji, jak je narocna, jakym stylem je psana, nemluvim o neprogramator­skych vecech typu licence, udrzba, atd..).

Dale by bylo hezke kdyby knihovny psali lide kteri rozumi tomu co pisou, o cem se da nekdy i docela pochybovat, minimalne do doby nez si clovek zkusi napsat vlastni knihovnu na to same a zjisti ze to zas az tak spatne nebylo. ;)

A samozrejme i kdyz clovek pouziva nejakou js knihovnu, alespon zakladnou syntax js by umet mel. (ja nesplnuji zatim ani tohle, porad to odsouvam a pokazde kdyz potrebuji nejakej kratickej js, tak mne zachrani to ze je tak ohebnej a tolerantni, ale ja aspon vim co nevim, tak se vyhybam delani vetsich js kousku kodu, dokud si nenajdu konecne cas se do nej seriozne ponorit)

Mne od toho dlouho odrazovala roztristenost web browseru (de facto nema se samotnym jazykem nic, ale web browser je proste hodne oblibena jscript platforma), tak jsem zavrhoval celkove jazyk. Az posledni dobou mu venuji vice pozornosti a zatim spis prijemne prekvapuje, i kdyz mi teda uplne prirozene nesednul, ja jsem spis na low level veci, to vic odpovida memu mysleni. Ale to taky neni chyba js. :)

Bauglir

Tady stojí za reakci jedna věc „Mne od toho dlouho odrazovala roztristenost web browseru … , tak jsem zavrhoval celkove jazyk.“
A knihovny mají většinou právě tu vlastnost, že fungují všude stejně, nad rozdílností implementace / chybou implementace si nemůsíte lámat hlavu, knihovna o nich ví a podle toho vykonává kód :)

junix

„…Kdo přečetl zdrojáky všech linuxových knihoven, které kdy použil, ať se přihlásí, u Win tu šanci ani nedostanete…“

My sice ne, ale u takovych projektu, jake jste zminil, kod nekdo reviduje, coz je podminka akceptace zmeny/rozsireni, nekdo ho testuje, a take – zmena vznika na zaklade nejake potreby a nasledne analyzy. Takove projekty maji roadmapu. Cil, navrh, architekturu, treba dilci.

Knihovny, jako jQuery casto nic z toho nemaji. Maximalne testing, „aby to aspon fungovalo“. Ale nejake review, nebo dokonce design.
Staci, ze nekdo jednou takovy „hnuj“ vystavi, nekdo dalsi ho pouzije, a uz se siri jako virus.

A pak v praxi jen velmi tezko rozlisite, jestli dany produkt je dobry (verim, ze Google closure, YUI a dalsi jsou), nebo ne. A jeste mene to vi vas sef, ktery vi jen, ze „jQuery je rozsirenejsi, takze to udelej v jQuery“ ;)

Palo

BTW: mi pouzivame toto:
http://www.smartclient.com/

kliknite si na demos alebo priamo pre Javistov cez GWT binding:
http://www.smartclient.com/smartgwt/showcase/
Mozte krasne programovat JavaScript aplikacie v Jave v bohatom GUI s bezkonkurencnymi prvkami. Cela kniznica je GPL a o JavaScript nemusite ani vediet ze existuje.

Enjoy

Aleš Roubíček

Ne na vše je OOP vhodným nástrojem. jQuery jde cestou funkcionálního programování a není na tom vůbec nic špatného. Jeho užití je snadné i pro lidi, co nejsou v JS zběhlí, najdou spoustu plug-inů a velice snadno a rychle vytvoří věci, které fungují. Obrovsky se tím snižují náklady na vývoj.

Aleš Roubíček

Ale, to já nikde netvrdím. :) Já říkám, že se snadno používá lidem, kteří nemají znalosti JS. Jako DSL pro práci s DOMem je jQuery prostě bezkonkurenční.

BTW plug-in přeci klidně můžeš napsat objektově a pro jQuery udělat jen fasádu, která integruje tvůj plug-in konvenčním způsobem.

Martin Soušek

Detaily toho pálení se pochlubíte? To musel být extra průser, když se to stalo tak zkušenému js programátorovi! Třeba by se mohli ostatní poučit a vyvarovat.

Martin Soušek

Tak to jsem zvědav, na spuštění. To musí být bomba!

Ale trošku mi to připomíná prezentaci jednoho člověka na Google Dev Day, který nadšeně vyprávěl o svém super projektu na editaci stránek v prohlížeči, na kterém pracuje tým 5 lidí už 3 roky a investor do toho sype miliony. Programované to bylo v GWT a už několikrát to portovali na novou verzi GWT. A následovala prezentace, kde ukázal tak neuvěřitelný shit, až jsem zapomněl zavřít pusu :)

aprilchild

Nevim, jestli bomba, ale neverejne uz to bezi pres par mesicu :). Nechci to psat sem, ale muzete mi poslat mail a dostanete pristup. Dan to zacal, pak jsme to vyvijeli spolu, vysledna podoba uz vznikala jinak.

martinsousek

Poslal jsem mail.

Ale jestli jde o ten editůrek, tak vám řeknu rovnou, že jste blázni :)

Lokutus

Odvážím se tvrdit, že tímhle si projde snad každý vývojář.
Jinak perfektně popsáno.

xy

tou usilovnou praci na vlastni pest jak lici daniel? ja bych rekl ze ne… poznal jsem nekolik programatoru v zamestnani, a nikdo… NIKDO z nich nebyl takovy, aby po praci na necem jeste delal…

xy

heh, tak to ja jsem neco podobneho :)) vyvojem svych 4. projektu jsem v souctu taky stravil 10 let, a z toho jen 1 se mi podarilo dokoncit :( ;). btw vsechno to byly windows aplikace, tedy newebove… delal jsem je v dobe, kdy internet jeste nebyl tak popularni… dneska nevim jestli bych jeste delal win aplikaci…….. tezko rict :(.

no a jak to dopadlo s tim projektem a proc spalil? mam to chapat jako ze jsi chtel vytvorit neco svyho, ze jsi pracoval na necem svym, a kyzeny efekt se stejne nedostavil v tom, ze se projekt nestal popularnim.. nebo jak. (to neni vyslech, ale zvedavost). ;)

keff

Já jsem taky zvědavý, a rád bych na zdrojáku viděl rubriku Post mortem, jako má např. Gamasutra o hrách – s články popisující zpětně po dokončení webových projektů co se povedlo, proč se to dělalo zrovna takhle, kde se vývojáři spálili, atd., a to z programátorského, architektonického i marketingového hlediska… :)

Martin Malý

Rubrika „post mortem“ není vůbec špatný nápad! Ještě ale najít někoho, kdo bude schopen a ochoten rozpitvat vlastní chyby, kterých se dopustil v existujícím projektu ;)

Bauglir

Pokud hledáte knihovnu s objektovými vychytávkami, nepoužívejte jQuery, její je účel je odstínit programátora od DOM. Jedná se o knihovnu, která nahrazuje DOM, nic víc. A nic víc není ani jejím účelem (jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development.). Jedná se jenom o API zaměřené na úzkou část. Asi jako byste libmysql nadával za to, že neumí reflexi mezi řádkem tabulky a objektem: není na to určená.
A proto se jQuery používá, je to velmi jednoduchá. A jestli v ní někdo zbastlí šílený plugin není chybou jQuery, ale programátora :)

xy

zajimavy prispevek

junix

Konstrukce pro vytvoreni tridy, uvedena v clanku, je velmi pekna. Je velmi blizka pristupu deklarativnich jazyku, ktere pro tyto ucely prave pouzivaji klicova slova a definicni syntakticke konstrukce.

Na druhou stranu, pristup striktne objektovych jazyku jde opacnou cestou, ktera je urcite nemene zajimava. Jazykove konstrukce minimalizovat, a co nejvice problemu resit prave pouze principem „objekt“ – „zprava“ (volani metody).

To co zde nyni uvedu neni v souladu s doporucenim clanku (se kterym jinak souhlasim :) ), nemenit built in objekty. Rozsirim nasledujicim zpusobem Function:

Function.prototype.extend = function(constructor) {
    function parent() {};
    parent.prototype = this.prototype;
    constructor.prototype = new parent();
    return constructor;
}

Function.prototype.mixin = function(mixin) {
    for(var i in mixin.prototype) this.prototype[i] = mixin.prototype[i];
    return this;
}

var IFace = Object.extend(
    function() {}
);

IFace.prototype.show = function() {return this.name;}

var MyObject = Object.extend(
    function(name) {this.name = name;}
);

var Other = MyObject.extend(
    function(name, car) {
    MyObject.call(this, name); this.car = car;
    }
).mixin(IFace);

alert(new Other('Jmeno', 5).show());

Vytvoreni potomka je tim padem „pouze“ volani metody extend na predkovi (coz dava i smysl). V prikladu je parametrem pouze primo konstruktor, ale muze zde byt i komplet definice.
No a zminene mixovani je opet pouze metoda, tentokrat uz primo daneho „potomka“.

Toto neni zadny spor s clankem. Vysledek bude uplne stejny (pokud se tedy doplni o nastavovani constructor a __superClass, coz pro ilustraci neni potreba). Pouze jiny pristup a dalsi demonstrace variability a svobody vyjadreni v JavaScriptu :)

Michal Augustýn

Přesně tenhle způsob zápisu dědičnosti (včetně názvu metody rozšiřující Function) jsem popsal ve svém článku :)

junix

To je velmi pekny clanek. Myslim, ze je trochu skoda, ze internet je takove roztristene medium. Informace jsou rozesete po ruznych clancich, a aby si clovek udelal kompletni prehled, musi hodne hledat, a odpovedi nachazi po castech (to je dano i tim, ze rozsah clanku je vetsinou omezen tak, aby byl stravitelny behem desitek minut).

Co tak se pustit do neceho vetsiho? Treba pdf kniha? Bylo by hezke mit vsechno pohromade, od zakladu po pokrocile techniky.

Michal Augustýn

Takovou myšlenku jsem měl taky a proto jsem dal ke stažení článek ve formě PDF (odkaz na konci článku). Ale Ty máš možná na mysli ještě nějaké pokročilejší techniky, které já tak nějak nepotřebuju, takže je moc nepoužívám, takže o nich ani nehodlám psát…

jjjjj

myslel som si ze o JS co to viem ale vdaka tomuto serialu som sa dozvedel ze este vela neviem. bol by som zvedavy hlavne na AOP v JS :-O

PavelO

Mohl byste ukázat jak přepsat tento syntax sugar ($class) tak, aby fungoval s node.js systémem modulů?
Jednotlivé přepsání funguje pro psaní třídy, ale to je všechno, není dědění, polymorfismus a ani se neukládají atributy rodičovské třídy.

var func = function(definition){
    var constructor = definition.constructor; 
    var parent = definition.Extends;
    if (parent) {
        var F = function() { };
        constructor._superClass = F.prototype = parent.prototype;
        constructor.prototype = new F();
    }
    for (var key in definition) {
        constructor.prototype[key] = definition[key];
    }
    constructor.prototype.constructor = constructor;
    return constructor;
};
module.exports.new = func;

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.