Kopie globalniho pole POST – PHP – Fórum – Programujte.com

Zajimá mně jakým způsobem pracujete Vy s globálním polem. Jde mi o to že někdo tvrdí že s polem $_POST["cisloZvenku"], se má pracovat v nezměněné podobě, tedy určitě ne takto - $cisloZvenku = $_POST["cisloZvenku"] protože jinak je to nebezpečné s tím souhlasím . V knize PHP6 programujeme profesionalně zase používají kopii pole, ta kopie je privátní takže si myslím že to je bezpečné = že se k ní nedá jen tak přistoupit, tak mně zajímá jak je to vlastně správně, nahodím sem ilustrační ukázku.

//takto to řeší v knize PHP6 programujeme profesionalne
Class Pocitej
{
    $private $_mojeCislo = 1;
    $private $_ciziCislo; // kopie pole
    $private $_vysledek; 
    
    public function __construct()
    {
        $this->_ciziCislo = $_POST["cisloZvenku"];
    }

    public function secti()
    {
        $this->_vysledek = $this->_mojeCislo + $this->_ciziCislo;
        return $this->_vysledek;
    }
}

a v případě nezměněné podoby by kód vypadalo takto

// nezměněná podoba
Class Pocitej
{
    $private $_mojeCislo = 1;
    $private $_vysledek; 

    public function secti()
    {
        $this->_vysledek = $this->_mojeCislo + $_POST["cisloZvenku"];
        return $this->_vysledek;
    }
}

Ta podtržítková notace u private vlastností je již pravděpodobně přežitek, dávám je tam jen pro ilustraci,  s příchodem PSR-1 je doporučováno $StudlyCaps, $under_score, $camelCase, ovšem mně osobně to podtržítko jasně dává najevo co je privátní . Připomínám že kniha je z roku 2010 ale pořád si myslím že tam je pár užitečných kusů kódu který se daj ještě dnes dobře použít. Zajímá mně jak se to dělá profesionálně. Předem dík za odpovědi.

#1 lubos
Podle mne je špatně obojí. Pro podobný účel bych použil tuto variantu: 

<?php

Class Pocitani {
    $private $mojeCislo = 1;
    $private $ciziCislo;
    $private $vysledek; 

    public function __construct($data) {
        $this->ciziCislo = 0 + $data["cisloZvenku"];
    }

    public function secti() {
        $this->vysledek = $this->mojeCislo + $this->ciziCislo;
    }

    function __toString() {
        return "Výsledek je: $this->vysledek";
    }
}

$pocitani = new Pocitani($_POST);
$pocitani->secti();
echo $pocitani;

Používání globálních proměnných uvnitř metod je velmi nepříjemné, pokud chceš provozovat TDD. Globální proměnné i třídy se totiž nedají mockovat. Daleko jednodušší a elegantnější je vrazit to do metody (resp. konstruktoru) jako parametr.

O výkon se bát nemusíš. Pole se fyzicky předává pouze odkazem. Kopíruje se teprve tehdy, když se v něm pokusíš něco změnit.

Tu metodu secti() jsem rozdělil na dvě proto, že metoda má buď něco dělat (procedura), anebo vracet nějakou hodnotu (funkce). Nikdy obojí. U funkce je přípustné modifikovat pouze lokální proměnné, což atributy nesplňují.

Dilema ohledně public/private/protected u proměnných mám vyřešeno: Všechny mám private.

#1 lubos
Ve druhém případě ta metoda může vypadat třeba takto: 

    public function secti($data) {
        $this->vysledek = $this->mojeCislo + $data["cisloZvenku"];
    }

#3 Kit
dík za odpověď ještě mám dvě otázky

1) když používáš jen private tak to znamená že v tvých projektech nepoužíváš dědičnost (potected)

2) kde mám sehnat nějaký tutoriál kde se dozvím co má dělat funkce a nebo procedura , myslím to samozřejmě obecně, spíš mi jde o nějaký PHP ALMANACH.  Z čeho jsi se Ty např. učil tyhle a další jiná pravidla ?.

#4 lubos

1. Dědičnost používám. Budeš se divit, protected v ní nepotřebuji. Krásně funguje i s private.
2. Myslím, že jsem to našel v knize Clean Code, česky Dokonalý kód. Doporučuji.

Obecně rozdělení procedura/funkce platí v té podobě, jak jsem to napsal. Pokud to porušíš, je to označováno jako side-effect, neboli postranní efekt. Fungovat to může, ale pokud něco nefunguje, tak se taková chyba hledá hodně špatně. Dnešní programování je hodně zaměřeno na takový zápis kódu, aby se případná chyba hledala co nejlépe.

Jako PHP almanach poslouží stránka http://php.net - z ní čerpám téměř vše. Je tam toho asi 12300 stran. Nenajdeš tam však obecné rady, viz procedura/funkce.

Hodně mi pomáhá jazykový cit: Procedura je od slova proces, tedy že něco dělá podle mého příkazu. Funkce v matematice vždy vrací nějakou hodnotu, kterou chci získat. Podobně řeším metody POST vs. GET, dědičnost vs. kompozici apod.

V OOP platí hlavně pravidlo: "Tell, don't ask", tedy neptej se a přikazuj. Paradoxně v PHP mají všechny metody na začátku klíčové slovo "function".

#5 Kit
já osobně taky považuju php.net za velmi poučný manuál ale moderní programovací praktiky tam jsou v nějakém tutoriálu  k pohledání. Na internetu jsem našel dvě knihy , http://knihy.cpress.cz/…aly-kod.html a http://knihy.cpress.cz/cisty-kod.html. Já jsem programátor CNC strojů a s tímhle druhem programování nemá moje práce ani zdánlivě nic společného, takže jsem vždy rád za každou dobrou radu . Já potřebuju super knihu ze které se naučím ty nejmodernější praktiky, protože když napíšu kus kódu a narazím na nějaký problém a zeptám se tady na fóru tak mi většinou zrovna Ty odpovíš, že je to či ono špatně, takže se zase vracím na začátek. PHP je můj koníček a mám na něj jen něco přes hodinu denně, tak se mi nechce se pořád vracet na začátek, když udělám někde v kódu chybu tak mi nevadí se vrátit  a opravit to ale když je celý kód jedna velká chyba tak to už naštve.

#6 lubos
Měl jsem na mysli tu knihu, kterou napsal Robert C. Martin. Za dalšího velikána považuji Martina Fowlera. V podstatě každá kniha od těchto dvou pánů je vynikající. Nezabývají se příliš konkrétními jazyky (ukázky bývají v Javě, ale jsou přenositelné), ale hlavně metodikou.

Knihu PHP6 programujeme profesionálně neznám. Nekoupil jsem si ji, protože PHP6 neexistuje a zřejmě ani existovat nebude. Brzy vyjde PHP7 (nebo už vyšlo?)

Své první aplikace jsem napsal úplně špatným stylem. Některé z nich dosud fungují a není důvod na nich nic cokoli měnit. Na některých dokonce částečně závisí chod firmy, ale protože fungují bezchybně, není důvod do nich zasahovat.

Nové aplikace však už navrhuji výhradně objektově. Oblíbil jsem si TDD, bez kterého dělám už jen prototypy, ze kterých se stejně postupně stanou testy. Možná některá z mých vyjádření zní až příliš tvrdě, ale je to jen důsledkem tvrdých nárazů, když jsem něco udělal např. globálně.

Takže pokud máš jen hodinku denně na PHP, tak v té hodince klidně můžeš sem poslat, čemu nerozumíš nebo ze kterých variant si máš vybrat. Takových tazatelů tady totiž máme málo a chybí tu.

Pokud ti něco zkritizuji, tak ti chci ukázat lepší cestu, kterou v některých případech nenajdeš nikde jinde. Dělám s PHP spoustu let a některé své poznatky jsem dosud nezveřejnil v nějaké ucelenější podobě, ale spíš je rozdávám po fórech. Často za to sklízím jen posměch :)

#7 Kit
Čemu ty říkáš kritika tomu já říkám velice vzácná rada, Líbí se mi tvůj styl psaní kódu bez setterů a getterů. a taky se mi líbí tvůj "jen private" přístup. Dokonce se mi líbí jakým zpusobem jsi si svůj styl obhájil před pár dny s ondřejem v tomto vlákně http://programujte.com/…zvu-getteru/ .

Když jsem dopsal svůj předchozí příspěvek, řekl jsem si že si svůj projekt dokončím  přestože bude napsaný neobratně, to co jsi mi potom napsal o tvých prvotinách ve firmě, mně jen přesvědčilo že to má smysl, nepřestávat  a naučit se programovat z vlastních chyb, já si svých chyb cením, protože pokud ty chyby sám napravím tak je to pro mně ta největší škola kterou můžu dostat ale pokud už nevím kudy kam a pomůže mi někdo jako ty tak je to pro mně ještě cennější ,obdržet zkušenost někoho kdo je o několik řádů dál než já, toho je schopno jen málo lidí ,proto ne kritika ale velice vzácná rada a je pravda že tvoje rady mně vždycky posunuly dost dopředu.

Tvých rad si cením už jen proto že nepřemýšlýš uniformně, jako celé stádo jiných programátorů, moje zkušenost ukázala že jen ten kdo jde proti proudu dojde dál než ten kdo plave s proudem.

Neber můj příspěvek jako VDP "VlezDoPrdelení", ale jen jako poděkování za to co jsi mně naučil, a doufám že na tomhle fóru ještě pár let zůstaneš,mám takový pocit že tě budu brzy potřebovat :  

#8 lubos
Můj styl je vydřený od základu a provázelo ho mnoho slepých uliček. Některé z nich na několika projektech dodnes fungují. Poučky od významných programátorů používám jen jako inspiraci a snažím se být sám sebou. Za mým stylem stojí stovky prototypů a benchmarků, které mi jednoznačně potvrdily spolehlivost, robustnost a efektivitu mých skriptů.

Settery/gettery/predikáty považuji za berličku programátorů, kteří chtějí programovat procedurálně tak, aby to vypadalo objektově. Privátní atributy jsem začal používat až po dlouhé úvaze, že jiný typ přístupu vlastně vůbec nepotřebuji. Lokální proměnné zase používám téměř všechny immutable - jsou tak o dost rychlejší. A moje třešnička na dortu (jednoslovní identifikátory proměnných/tříd/metod/rozhraní) je jen důsledkem toho všeho. Pokud jsem ve Tvém skriptu ponechal víceslovní, bylo to jen proto, abych zachoval alespoň nějakou návaznost na původní kód.

O zbytečnosti komentářů jsi již určitě ode mne také četl - vlastně to mám v podpisu. Od prvopočátku svého programování jsem se vždy snažil o to, aby můj program byl čitelný i bez komentářů a dal se číst jako pohádka na dobrou noc. Výjimkou je snad jen Assembler, kde to bez komentářů moc nejde.

Z tvých příspěvků cítím programátorské zkušenosti. Sice z jiného typu úloh, ale programátorské. Myslím si, že se mi také budeš někdy hodit, až se budu ptát třeba na Arduino, se kterým zrovna začínám.

#9 Kit
[...]

Settery/gettery/predikáty považuji za berličku programátorů, kteří chtějí programovat procedurálně tak, aby to vypadalo objektově.

[...]

Mrkni ještě sem, Kite.   

Martin Fowler: GetterEradicator

[...]

Zmíněný přístup mi přijde velmi sympatický, ale obávám se, že říkat lidem aby se zcela vyhli getterům je hloupé. Je až příliš mnoho případů, kdy objekty spolu musí spolupracovat způsobem, že si vyměňují data, což vede ke skutečné potřebě getterů.

Pokud se snažíme nalézt jednoduché, ale univerzální pravidlo, líbí se mi to, o němž jsem poprvé slyšel od Kenta Becka, abychom se báli případů, kde část kódu invokuje více než jednu metodu na jiném objektu. Což se stává v případě použití accessorů a jiných metod, které dávají větší smysl.

Pokud je možné dotázat se objektu na dva kousky dat kvůli určité operaci, nešlo by požadavek sloučit do jednoho, který nám dodá data, na nichž je operace již provedena? Pokud řeknete objektu, aby udělal dvě věci, nedaly by se požadavky sloučit do jednoho příkazu? Samozřejmě, nastane spousta situací, kde sloučení možné není, ale vždy je dobré se nad tou otázkou minimálně zamyslet.

[...]

#10 ondrej39
Když si to přečteš pořádně, tak jsme v souladu. Martin Fowler připouští použití getterů/setterů tam, kde jiná možnost již není. Snažím se těmto situacím předcházet, abych je nepotřeboval.

#11 Kit
Když ty každý týden říkáš něco jiného, to je pak těžký se s tebou domluvit, chlape.

#12 ondrej39
Vidíš v tom snad nějaký rozpor? Accessorům se vyhýbám. Martin Fowler také, i když připouští, že jsou někdy potřebné. Zní snad můj přístup příliš kategoricky? Tak zkusím svůj postoj přeformulovat:

• Accessory by se neměly používat.
• Všechny atributy objektu by měly být privátními.

Je to tak lepší?

#13 Kit
Když jeden týden píšeš, že gettery jsou úplně zbytečné, porušují zapouzdření objektu a k datům se dá přistoupit jinak a druhý týden je tvůj názor ten, že pokud musíš, vlastně gettery také používáš, tak jsou to vskutku názory, které si odporují.

Anebo možná už jsem tak zblblej a nerozumím českému jazyku, pak je problém u mě.

#14 ondrej39
Pokud mám ze třídy, kterou jsem nedělal, definován v rozhraní nějaký getter či setter, tak ho samozřejmě použít musím. Příkladem budiž Exception::getMessage(). Sám však takové metody nepíši, protože to považuji za low-level, který se hodí možná pro procedurální aplikaci, ale určitě ne pro objektovou.

Za gettery/settery považuji metody, které pracují s jednotlivým atributem objektu nebo to jen předstírají. Takové accessory nepoužívám. Důležité je pracovat s objektem jako celkem. Metody typu insert() či delete() jsou také accessory. Nepracují však s atributy, ale s celým objektem. Objekt sám ví nejlépe, co má s jejich parametry dělat a které atributy si má modifikovat.

Resil bych to podobne jako KIT. Bud bych s tim pracoval primo a nebo pres promennou. Totiz, kdyz to das jako promennou funkce, tak tam muzes vlozit vlastni data. Coz je sikovne pro testovani nebo simulaci funkce. Kdyz chces treba uzivateli udelat demicko, ze kdyz zada to a to, tak tvuj program vyplodi to ci ono. Dostanes realne vysledky, ktere se zmeni pri kazdem upgradu funkce. A nebudes mit dve rozdilne kopie, jednu v napovede a upgradnutou funkci v programu.

#4 lubos
Ještě takový doplněk k výše uvedenému. V reálu mívám ten konstruktor o něco málo jednodušší: 

Class Pocitani {
    private $data;

    public function __construct(array $data) {
        $this->data = $data;
    }
// :

}

Má to pár skvělých vlastností:

• mohu dělat tzv. opožděnou validaci
• mohu si z toho pole $data (resp. slovníku) vybrat všechny údaje, které potřebuji
• ten slovník $data je (na rozdíl od objektu) ochráněn před cizími vlivy
• nemůže mě nikdo nařknout, že moje třída porušuje SRP ($data je jen kopií dat z vnějšku, používám je readonly)
• volání konstruktoru je velmi jednoduché, typicky $vypocet = new Pocitani($_POST);
• dodržuji Déméteřin zákon
• třídy jsou velmi krátké a dělají jen to, co mají
• je to rychlé a efektivní

Všimni si ještě slova "array" před $data v parametru konstruktoru. Nevěřil bys, jak významně to pomáhá při ladění aplikací. PHP 7.0 to bude mít i na primitivní typy.