1. díl - Úvod do objektově orientovaného programování v PHP

PHP Objektově orientované programování Úvod do objektově orientovaného programování v PHP American English version English version

Vítejte u prvního dílu úvodu do objektově orientovaného programování v PHP. Sekci Jednoduchý dynamický web v PHP již máme zasebou. V této sekci se naučíme objektově programovat a hlavně objektově myslet. Je to něco trochu jiného, než jsme dělali doteď a webovou aplikaci už nebudeme chápat skript s příkazy, které interpret vykonává odshora dolů.

Proč programovat objektově

Znalost objektově orientovaného programování v PHP je naprosto klíčová, jelikož umožňuje tvořit architekturu webových aplikací (oddělit výstup HTML od logiky) a používat komponenty třetích stran. Vyvíjet vážnější projekt bez objektů je pracnější, náročnější a výsledek bude vždy nekvalitní.

Objektově orientované programování (dále jen OOP) nevzniklo náhodou, ale je důsledkem vývoje, který k němu směřoval. Jedná se o moderní metodiku vývoje softwaru, kterou podporuje většina programovacích jazyků. Častou chybou je, že se lidé domnívají, že OOP se využívá pouze při psaní určitého druhu programů a jinak je na škodu. Opak je pravdou - OOP je filosofie, je to nový pohled na funkci programu a komunikaci mezi jeho jednotlivými částmi. Mělo by se používat vždy, ať už děláme malou utilitku nebo složitý databázový systém. OOP není jen technika nebo nějaká doporučená struktura programu, je to hlavně nový způsob myšlení, nový náhled na problémy a nová éra ve vývoji softwaru.

Abychom porozuměli výhodám, které nám OOP přináší, podíváme se krátce do historie nato, jak se programovalo dříve.

Evoluce metodik

Mezi tím, jak se programovalo před 40ti lety a jak se programuje dnes, je velký rozdíl. První počítače neoplývaly velkým výkonem a i jejich software nebyl nijak složitý. Vývoj hardwaru je však natolik rychlý, že se počet tranzistorů v mikroprocesorech každý rok zdvojnásobí (Moorův zákon). Bohužel, lidé se nedokáží rozvíjet tak rychle, jako se rozvíjí hardware. Stále rychlejší počítače vyžadují stále složitější a složitější software (resp. lidé toho chtějí po počítačích stále více a více). Když se v jedné chvíli zjistilo, že okolo 90% softwaru je vytvořeno se zpožděním, s dodatečnými náklady nebo selhalo úplně, hledaly se nové cesty, jak programy psát. Vystřídalo se tak několik přístupů, přesněji se jim říká paradigma (chápejte jako směr myšlení). My si je zde popíšeme.

1. Strojový kód

Program byl jen souborem instrukcí, kde jsme neměli žádnou možnost pojmenovávat proměnné nebo zadávat matematické výrazy. Zdrojový kód byl samozřejmě specifický pro daný hardware (procesor). Toto paradigma bylo brzy nahrazeno.

Program sčítající dvě čísla (83 a -2) by vypadal např. takto:

2104
1105
3106
7001
0053
FFFE
0000

Jak vidíte, programovat ve strojovém kódu určitě není to pravé a i taková banalita má mnoho řádků.

2. Nestrukturované paradigma

Nestrukturovaný přístup je podobný assemblerům, ale instrukce jsou pojmenované hesly, čili je částečně lidsky čitelný. Přístup na nějakou dobu umožnil vytvářet komplexnější programy. Bylo tu však stále mnoho úskalí: Jediná možnost, jak udělat něco vícekrát nebo jak se v kódu větvit, byl příkaz GOTO. GOTO nám umožňuje "skákat" na jednotlivá místa v programu. Místa byla dříve specifikována číslem řádku zdrojového kódu, což je samozřejmě nepraktické. Když do kódu vložíme nový řádek, čísla přestanou souhlasit a celý kód je rozbitý. Později vznikla možnost definovat tzv. "návěstí". Takto se obcházela např. absence cyklů. Takovýto způsob psaní programů je samozřejmě velice nepřehledný a brzy přestal postačovat pro vývoj složitějších programů.

Náš příklad by vypadal v ASM takto:

ORG 100
LDA A
ADD B
STA C
HLT
DEC 83
DEC –2
DEC 0
END

Uvědomme si, že obrovské rozšíření počítačů za posledních několik dekád má na svědomí růst poptávky po softwaru a logicky také růst poptávky po programátorech. Jistě existují lidé, kteří dokáží bez chyby psát programy v ASM nebo jiných nízkých jazycích, ale kolik jich je? A kolik si asi za takovou nadlidskou práci účtují? Je potřeba psát programy tak, aby i méně zkušení programátoři dokázali psát kvalitní programy a nepotřebovali k tvorbě jednoduché utilitky 5 let praxe.

3. Strukturované programování

Strukturované programování je první paradigma, které se udrželo delší dobu a opravdu chvíli postačovalo pro vývoj nových programů. Programujeme pomocí cyklů a větvení. To je v podstatě to, kam jsme se doteď dostali.

Program lze rozložit logicky do funkcí, to jsme si již také vyzkoušeli. U strukturovaného programování hovoříme o tzv. funkcionální dekompozici. Problém se rozloží na několik podproblémů a každý podproblém potom řeší určitá funkce s parametry.

Nevýhodou je, že funkce umí jen jednu činnost, když chceme něco jiného, musíme napsat novou. Neexistuje totiž způsob, jak vzít starý kód a jen trochu ho modifikovat, musíme psát znovu a znovu - vznikají zbytečné náklady a chyby. Tuto nevýhodu lze částečně obejít pomocí parametrizace funkcí (počet parametrů poté ale rychle narůstá) nebo použitím globálních proměnných. S globálními daty vzniká však nové nebezpečí - funkce mají přístup k datům ostatních. To je začátek konce, nikdy totiž neuhlídáme, aby někde nedošlo k přepsání glob. dat mezi funkcemi a začne docházet k nekontrolovatelným problémům. Bez objektů se také velmi špatně tvoří nějaká architektura, která je u webových aplikací velmi důležitá. Celý program se potom skládá ze stovek nezapouzdřených funkcí a špatně se udržuje. Každá úprava programu zvyšuje složitost, program potom nutně dojde do stavu, kdy náklady na přidávání nových funkcí vzrostou na tolik, že se program již nevyplatí rozšiřovat. Zástupci tohoto přístupu jsou například jazyky C a Pascal. PHP je takovým hybridem, kde se tento přístup také objekvuje. Je to díky tomu, že jazyk vznikl v době, kdy OOP ještě nebylo rozšířené.

Náš příklad by vypadal takto:

function secti($a, $b)
{
        return $a + $b;
}
$c = secti(83, -2);

Mezi strukturovaným programováním a objektově orientovaným programováním existoval ještě mezičlánek, tzv. modulární programování, která nám umožňuje zapouzdřit určitou funkcionalitu do modulů. Stále však neexistuje způsob, jak již napsaný kód modifikovat a znovu využít.

Jak již jsem se zmínil na začátku článku, někdy se uvádí, že se jednoduché programy mají psát neobjektově, tedy strukturovaně. Není to však pravda. Když opomineme fakt, že porušujeme filozofii OOP jako takovou, nikdy nemůžeme vědět, zda se tento program neuchytí a z malé utilitky se nestane něco vážnějšího. Potom opět nutně dospějeme do stavu, kdy program nebude možné dál rozšiřovat a budeme ho buď muset zahodit nebo celý přepsat s pomocí OOP.

Neobjektovým metodám psaní kódu se přezdívá "spaghetti code" pro jejich nepřehlednost (protože špagety jsou zamotané).

Objektově orientovaný přístup

Jedná se o filozofii a způsob myšlení, designu a implementace, kde klademe důraz na znovupoužitel­nost. Přístup nalézá inspiraci v průmyslové revoluci - vynález základních komponent, které budeme dále využívat (např. když stavíme dům, nebudeme si pálit cihly a soustružit šroubky, prostě je již máme hotové).

Poskládání programu z komponent je výhodnější a levnější. Můžeme mu věřit, je otestovaný (o komponentách se ví, že fungují, jsou otestovány a udržovány). Pokud je někde chyba, stačí ji opravit na jednom místě. Jsme motivováni k psaní kódu přehledně a dobře, protože ho po nás používají druzí nebo my sami v dalších projektech (přiznejme si, že člověk je od přírody líný a kdyby nevěděl, že se jeho kód bude znovu využívat, nesnažil by se ho psát kvalitně :) ).

Znalosti, které jsme se doteď naučili, samozřejmě budeme používat dál. Náš kód budeme pouze jinak strukturovat a to do komunikujících objektů.

Ještě si jen pro ilustraci ukažme opět náš příklad, tentokrát v objektech. Funkce sečti již nebude volně někde poletovat, ale bude patřit objektu sčítačka, který je jednou z komponent naší aplikace.

class Scitacka
{

        public function secti($a, $b)
        {
                return $a + $b;
        }

}

$scitacka = new Scitacka();
$c = $scitacka->secti(83, -2);

Kód vám zatím asi nic moc neříká. Napravíme to příště, kdy si vše podrobně vysvětlíme a vytvoříme si svou první objektovou aplikaci :)


 

  Aktivity (1)

Článek pro vás napsal David Čápka
Avatar
Autor pracuje jako softwarový architekt a pedagog na projektu ITnetwork.cz (a jeho zahraničních verzích). Velmi si váží svobody podnikání v naší zemi a věří, že když se člověk neštítí práce, tak dokáže úplně cokoli.
Unicorn College Autor se informační technologie naučil na Unicorn College - prestižní soukromé vysoké škole IT a ekonomie.

Jak se ti líbí článek?
Celkem (28 hlasů) :
55555


 



 

 

Komentáře
Zobrazit starší komentáře (17)

Avatar
Inoue Yūki
Redaktor
Avatar
Inoue Yūki:

Já bral CMS sczdavose za CMS, ne za framework. Proto jsem tak argumentoval.

Odpovědět 1.8.2013 15:35
Avatar
xnitrox
Člen
Avatar
xnitrox:

Hádám, že bys to své CMSko asi nenasdílel, pro inspiraci, jak by takový redakční systém měl vypadat... viď? :)

 
Odpovědět 5.8.2013 2:59
Avatar
Odpovídá na xnitrox
David Jančík [sczdavos]:

No, jako spoustu svých programů včetně ISIMu jsem dal jako open source. Potřebuju taky na něčem vydělávat, páč očekávat něco jako podporu, že mi někdo něco přispěje, to bych byl hodně naivní :D a kdybych dal i CMSko, tak to bych ho musel zprasit jako některé ty open source CMSka, aby to lidi nechtěli používat :D Se celkem snažim a jak jsem teď dělal web na zkoušku, tak jsem tam za 10 minut napojil šablonu s generováním obsahu a pak jsem jen pár hodin psal dodatečné fce. Takže to funguje přesně dle očekávání. Nicméně, můžeš se ptát, jak mám co řešené :)

Odpovědět 5.8.2013 7:11
Čím více času dostaneš, tím méně ho máš.
Avatar
vodacek
Redaktor
Avatar
Odpovídá na David Jančík [sczdavos]
vodacek:

vy ste škrt pane, to teda nevim jestli za váma dneska pojedu

 
Odpovědět 5.8.2013 8:06
Avatar
mkub
Redaktor
Avatar
mkub:

asi prejdem aj ja na OOP a sa vykaslem na klasiku ;)

 
Odpovědět 15.11.2013 19:36
Avatar
Kit
Redaktor
Avatar
Odpovídá na mkub
Kit:

Na klasiku se vykašlat nemusíš, pořád jí v programu zbude docela dost i když přejdeš na OOP.

Zrovna mě napadla taková blbinka - statický generátor Fibonacciho posloupnosti. Je to closure - na půli cesty k objektům.

<?php
function fibo() {
    static $a = 0;
    static $b = 1;
    $c = $a + $b;
    $a = $b;
    $b = $c;
    return $c;
}

for ($i = 1; $i <= 20; $i++) {
    echo fibo(), "\n";
}
Odpovědět 15.11.2013 20:00
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Avatar
mkub
Redaktor
Avatar
Odpovídá na Kit
mkub:

ja som to az tak dramaticky nemyslel, ale preco by som pracu s databazou neriesil cisto objektovo? a takisto aj profily uzivatelov preco by nemohli byt objekty?
cize ma caka velke prepisovanie celeho kodu + ochrana pred CSS a SQL Injection tam, kde ocakavam od uzivatela vstup

 
Odpovědět 15.11.2013 20:16
Avatar
Kit
Redaktor
Avatar
Odpovídá na mkub
Kit:

Pokud použiješ PDO, tak se tím zbavíš SQL injection. Podmínkou je samozřejmě použití prepared statements na všechny uživatelské vstupy.

XSS se zbavíš zase pomocí htmlspecialchars(), urlencode() a pár dalších funkcí, které aplikuješ na výstupních datech z databáze. To asi znáš.

Profil uživatele samozřejmě může být jako objekt, ale většinou ho stejně ani nebudeš vytvářet, protože není vždy potřebný. Zpravidla stačí ID přihlášeného uživatele v session.

Odpovědět  +1 15.11.2013 20:31
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Avatar
Jiří Gracík
Redaktor
Avatar
Odpovídá na Kit
Jiří Gracík:

A zvládl bys nějaký článek ohledně obrany proti CSRF? Začínám v tom pociťovat největší slabinu svých aplikací, možná i proto, že stále 100%-ně nerozumím principu některým typům útoku (četl jsem si o tom na soomu, ale ten článek je na mě moc složitý a poměrně vyčerpávající).

Editováno 15.11.2013 20:47
Odpovědět 15.11.2013 20:46
Creating websites is awesome till you see the result in another browser ...
Avatar
Kit
Redaktor
Avatar
Odpovídá na Jiří Gracík
Kit:

Myslím si, že na http://cs.wikipedia.org/…uest_forgery je dostatečně popsána ochrana:

  • modifikace dat zásadně jinak než metodou GET. Tedy POST, PUT a DELETE
  • autorizační token
Odpovědět 15.11.2013 20:57
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 10 zpráv z 27. Zobrazit vše