Dotaz: Zapouzdření php kódu

[Pavelec]

Ahoj. Pokud programuji procedurálně a nechci používat objekty, jak můžu zapoudřit jednotlivé části kodu bez použití funkcí? Dík

Odpovědi

[Josef Kufner]

Nejlépe tím, že použiješ objekty a jejich metody.

Pokud však máš masochistické záliby, můžeš začít zde.

[FrostyX]

Je to jen teoretická otázka jejímž cílem je rozšířit si obzory o tom, jakými způsoby lze programovat, nebo se to chystáš někde použít?

[FrostyX]

V prvním případě by se možná o nějakém "zapouzdření" dalo mluvit, třeba rozdělením jednotlivých kusů kódu mezi samostatné soubory? Možná? V druhém bych řekl, nedělej to, použij funkce, třídy, cokoliv můžeš.

[Radek Miček]

Co to vlastně je zapouzdření?

Například v zápiscích z kurzu Advanced Programming Languages z lekce o existenciálních typech definují zapouzdření takto:

data abstraction, which in the object-oriented programming world sometimes is called information hiding or encapsulation. This is a feature in which the type system hides internals of objects, enforcing an abstraction barrier between the implementer and the clients of the class. This abstraction barrier helps keep different parts of the system loosely coupled so they can be updated and maintained without close coordination.

Data abstraction is offered in its purest form by existential types. The idea is that we can hide part of a type τ and replace it with a type variable α. We write ∃α.τ to represent this type, where α may be mentioned inside τ. But because this type does not say what α is, no code receiving a value of this type can make use of knowledge of the hidden part of this type.

[Kit]

IMHO si někde přečetl, že OOP jsou delší, pomalejší, složitější, méně přehledné, ... a chce se tomu vyhnout.

[FrostyX]

Imho si přečetl, že je OOP náročné na systémové zdroje a chce přehnaně optimalizovat

[Kit]

Tuhle pomluvu na OOP jsem už také někde slyšel. Pořád tvrdím, že za to mohou chybně navržené gettery a settery

[H|H]

A oni jdou snad navrhnout chybně gettery a settery ? Co si pod tím mám představit, narážíš na něco konkrétního ?

[Kit]

Pokud getter jen předává hodnotu atributu a setter ho pouze nastavuje, je to špatně. Prostě se jimi plýtvá, ve většině případů je jejich použití zbytečné.

Názvy metod nemají být podstatná jména s nějakou předponou get/set (maďarská notace), ale slovesa. Atributy objektu mají být privátní a neměly by se nim dělat přístupové metody.

[Josef Kufner]

Pokud jazyk nemá podporu pro properties, jako např. C#, tak není moc jak to jinak udělat, než pomocí getterů a setterů, leda mít public proměnné, ale to se nehodí vždy.

Pointa triviálních get/set je v konzistentnosti API. Pokud potřebuju u pár setterů něco počítat, je lepší mít settery na všechno, neboť pak při použití není potřeba přemýšlet, zda tahle věc se nastavuje tak či onak. Stejně tak s gettery. Pokud bych se pokusil číst ještě nespočítanou hodnotu, mělo by to hodit výjimku, ale číst něco přes public proměnné a něco přes getter znamená kopec bordelu.

Takže pokud překladač daného jazyka zvládne triviální gettery a settery vyoptimalizovat (inline), není důvod si v tom dělat bordel (např. Qt v C++, kde setter je navíc i slotem pro signály). PHP nabízí __get a __set a volání nevyoptimalizuje, takže tam je lepší public proměnná a trocha magie, pokud je třeba. C# zas má nativní podporu pro properties, takže tam gettery a settery vůbec nemají co dělat. No a v Javě je kopec bordelu i tak, takže tam se to ztratí, ať se použije cokoliv

[Kit]

Public proměnné raději nebrat.

[Josef Kufner]

Pokud getter jen předává hodnotu atributu a setter ho pouze nastavuje, je to špatně. Prostě se jimi plýtvá, ve většině případů je jejich použití zbytečné.

Sám říkáš totéž. Nic jiného než getter/setter a public proměnná není.

[Kit]

Je. Použití doménové logiky.

[Josef Kufner]

Ale i té potřebuješ data nějak předat.

[Kit]

Buď konstruktorem, anebo metodou. Jak prosté. Nepředávám však data atributu, ale celému objektu. Voláním metody dávám objektu příkaz (vyjádřený nějakým slovesem) a v parametru mu dám nějaká data. Metoda v objektu rozhodne, jak se s daty naloží - název metody nijak nemusí nesouviset s vnitřní strukturou objektu, která by měla zůstat skrytá.

Když metodu nazvu $obj->setDatum($datum), tak odkrývám, že se uvnitř nachází atribut Datum. Porušuji zapouzdření a dělám tedy totéž, jako kdybych napsal $obj->datum = $datum. Druhý zápis je přehlednější.

Podobně místo $datum = $obj->getDatum() je vhodnější použít $datum = $obj->datum. Výraz $obj->datum na rozdíl od toho předchozího můžeš expandovat i ve stringu nebo v Heredoc.

Vnitřek může být skryt za metodami __get() a __set().

Abych předešel dalším dohadům: Používám postup popsaný v prvním odstavci. Názvy mých metod nijak nesouvisí s názvy atributů uvnitř mých objektů.

[Lucius]

asi nerozumim tomu, co je to to zapouzdreni, ale to ze z nazvu metody nema byt jasne co ta metoda dela slysim poprve a spis nez zapouzdreni bych to nazval skryvani - coz je k nicemu, naopak si myslim, ze z nazvu metody ma byt jasne co dela

[Kit]

Název metody nemá souviset s názvy atributů objektu, ale má být jasné, co s objektem dělá. Přečti si ještě jednou a pořádně, co jsem napsal.

[Lucius]

Nevim, at ctu jak ctu, tak jde o skryvani ne o zapouzdreni. Ale mozna je to tim ze nazvy jako $obj->setDatum($datum) nepouzivam, nekombinuju jazyky ani v nazvech fu, metod, promenych, parametru, konstant atp.

Ale obecne je zapuzdreni o tom, ze se z venku k vlastnostem objektu dostanete jen "predepsanou" cestou a to pres zpristupnene rozhrani. Jak pojmenovavat pak uz nema se zapouzdrenim nic spolecneho. Pokud tedy vas prispevek rika zhruba to tak s nim nemam problem a jen jsem neporozumel textu.

[Kit]

Pokud narážíš na to, že by správně mělo být

$obj->setDate($date)

tak jsi na omylu. Je to úplně stejně špatně.

Co znamená "predepsanou" cestou? To bych mohl klidně napsat $obj->date = $date a označit ten zápis jako předepsanou cestu.

[Lucius]

predepsanou sestou myslim to co jsem napsal - pres poskytnute rozhrani

[Kit]

No právě. Které rozhraní máš na mysli?

$obj->setDate($date);

nebo

$obj->date = $date;

Obojí je špatně. Ke druhému zápisu sice máme poskytnuté rozhraní, ale používá se obvykle jen u objektů třídy stdClass.

[Lucius]

$obj->date = $date; neni uziti rozhrani ale primy pristup k vlastnosti objektu - a tomu prave brani zapouzdreni

zapouzdreni se nestara o to jak je rozhrani pojmenovane, zapizdreni je zpusob/princip pristupu k vlastnostem objektu

kdyz se parta progrmatoru dohodne ze v projetku budou pouzivat pro pristup k vlastnostem A, B, atd. metody pojmenovane

setA(A)

setB(B)

atd.

tak jde porad o zapouzdreni, jen si tim treba komplikuji citelnost kodu ap. , ale zapouzdreni tim neporusuji

[Kit]

Zkus to vysvětlit programátorům v C#. PHP disponuje podobnými prostředky. Že by totéž v C# a v PHP nebylo totéž?

Kde máš definováno rozhraní setA a

setB

?

[Lucius]

prece v te tride - to jsou metody objektu pro pristup k vlastnostem objektu

[Josef Kufner]

$obj->date = $date; neni uziti rozhrani ale primy pristup k vlastnosti objektu

Public property je součást rozhranní a nijak to nekoliduje se zapouzdřením.

[Lucius]

tak pokud chcete nejakou vlastnost mit zverejnenou pak nejde o zapouzdreni, o kterem je tu rec

[Kit]

$obj->setDate($date);

také není zapouzdření, o kterém je tu řeč.

[Lucius]

Jak to?

je to public metoda ktera vam odstini co se v objektu stane - neresi co se v objektu stane, co je to datum - jestli retezec, objekt ..., proste na venek o tom nevite nic

[Kit]

Zápisy

$obj->setDate($date);
$obj->date = $date;

se liší pouze syntaxí, sémanticky jsou shodné. Proč bych měl v PHP dávat přednost prvnímu zápisu, když např. v C# je preferován ten druhý?

A proč bych měl používat některý z nich, když ani jeden nepotřebuji?

[Lucius]

Nerozumim v cem jsou shodne? jedno je prirazeni hodnoty primo atributu a druhe je volani nejake metody, ktera muze delat cokoli - muze napr predavanou hodnotu validovat, prevest na pozadovany format - proste volanim metody nevite nic o tom co se uvnitr deje, co to udela s objektem, nevite ani to jestli objekt vubec ma nejaky parametr date - to je princip zapouzdreni - z vnejsku netusite nic o tom jak je to v objektu realizovano, protoze to ani nepotrebujete ani nemate znat - znate jen rozrani.

[Kit]

Všechny požadované vlastnosti má i zápis

$obj->date = $date;

• nevím nic, co se uvnitř děje
• nevím, co to udělá s objektem
• nevím, jestli objekt má vůbec nějaký atribut date
• znám jen rozhraní

[Lucius]

? do nejake clenske promene priradim hodnotu 1 - tak jak to ze nevim co se deje? vim ze promena ma tuto hodnotu, tedy vlastnost objektu reprezentovana tou promenou ma tuto hodnotu 2 - vim tedy, co to udela s objektem - nastavi to vlastnost toho objektu na tu hodnotu 3 - ano to nevim a tak dojde k chybe - vyjimce pokud se takovy atribut pokusim nastavit 4 - rozhrani neznate pokud v predeslem rikate, ze nevite jestli ten tribut date existuje - neexistujci atribut neni soucasti rozhrani

Prave i tyto problemy uziti rozhrani resi - s rozhraim neresite jestli existuje konkretni vlastnost objektu, protoze k ni nepristupujete primo, neresite jestli te vlastnosti prirazujete platnou hodnotu, metoda setDate, kterou tu pro priklad uzivame, nic nerika o tom jestli objekt ma nejakou vlastnost date - klidne muze jen predavanou hodnotu nekam ukladat, vubec s ni nemusi v objektu nic nastavovat ...

[Kit]

• k proměnné přece v tom kódu také nepřistupuji přímo, ale přes setter
• o jakém rozhraní tady pořád píšeš? Žádné jsi nedefinoval, takže ani ve tvém případě ho neznám
• pokud se pokusím nastavit neexistující atribut, také dojde k chybě, resp. výjimce
• Jestli atribut date existuje nebo ne, záleží právě na tom rozhraní
• v mém zápisu se předávaná hodnota také může někam ukládat, například do databáze

[Lucius]

Vy pisete o "magickych metodach" (__set) ? nebo jaky setter?, ve vasem prikladu ukladate hodnotu primo do promenne - __set neni totez co verejne rozhrani objektu- rozhrani slouzi pro pristup k existujicim vlastnostem objektu, magicka metoda neexistujici vlastnost vytvari

rozhrani - jak jsem uvedl - v teto debate treba ta metoda setDate, kterou tu v prispevcich uzivame - proste public metoda toho objektu, ktera slouzi pro pristup k existujicim vlastnostem toho objektu

[Kit]

Ano, píši o magické metodě __set(), která se používá přesně tím způsobem, jaký jsem popsal. Volání takové metody je totožné s přístupem k veřejnému atributu.

Programátoři v C# tento postup používají stále, i když definice přístupových metod je poněkud odlišná - pro každou property píší samostatný getter a setter. PHP si vystačí s jedním getterem a jedním setterem pro všechny atributy.

[Lucius]

Ale zapozdreni neni o verejnem atributu, to je naopak o privatnim - z vnejsku nepristupnem a pokud ma byt pristupny tak jen pres verejne rozhrani.

__set() - neslouzi k zapouzdreni - protoze pres nej muzete pristupovat k cemukoli, i k tomu co nema byt pristupne z vnejsku + jeste neexistujici property pres nej muzete vytvaret, takze meni strukturu obj.

takze abyste mohl __set() pouzivat pro zapouzdreni tak z nej nakonec budete mit tak komplikovanou metodu (treba pres if, switch, atp.), ze to nakonec zadnou vyhodu nema

navic se muzete dostavat do problemu, ze pokud nekde v kody pres __set() vytvorite property a jinde ji pak pres __get() ctete, pak nekde zmenite tu cast kodu kde jste pouzival __set() (nevytvorite property), tak vsude jinde kde tu property ctete pres __get() mate chybu - objekt se nezmenil - jen jste mu nekde zapomnel pricarovat property - pri normalim rozhrani se pro vas nic nemeni - property obektu vzdy existuje a vy k ni pristupujete pres to rozhrani ...

takze abych to shrnul pres __set() udelat zapouzdreni nic nevylepsuje, neusnadnuje, naopak to jen zneprehledni kod

[Kit]

Přes __set() nemůžeš přistupovat k čemukoli. Zkus si tohle:

class Setter {
    private $date;

    private function setDate($date) {
        $this->date = $date;
    }

    function __set($key, $value) {
        $method = "set" . ucfirst($key);
        $this->$method($value);
    }
}

$obj = new Setter();
$obj->date = new DateTime();

Má to všechny vlastnosti, které jsi požadoval. Není tam žádný if ani switch, atribut $date je privátní. Od tvého řešení se liší pouze syntaxí volání.

Přiznám se však, že v této podobě bych to asi nepoužil, protože gettery, settery ani veřejné atributy obvykle nemám důvod používat.

Takze abych to shrnul: Udělat zapouzdření přes setDate() nic nevylepšuje ani neusnadňuje, naopak to jen znepřehlední kód.

[Lucius]

ja v tom zadny prinos nevidim - stejne tam ten setter setDate musite mit - kdyz se chcete vyhnout tem if, switch apod. jen to schovate jeste za jednu metodu - proste pridate dalsi vrstvu - v cem je ta vyhoda? proste jen ten ze se vam vic libi zapis $obj->date = new DateTime(); $obj->setDate(new DateTime());

normalne muzete pouzit u slozitejsich trid interface a implements pro ohlidani toho, ze ta trida zpristupnuje to co ma, jak to udelate se __set ?

Myslim, ze na tema zda pouzivat __set nebo settery je plno dalsich diskuzi. Ja az do predminuleho prispevku netusil, ze vam jde o to zda pouzivat __set, kdyby jo, do te debaty bych se ani nepoustel - to jestli pri zapisu usetrim par znaku me nebere.

[Kit]

Složitější třída? To bude asi taková, která porušuje SRP

Settery i __set() používat umím. Jen je považuji ve většině případů za zbytečné. Prostě se jimi v aplikacích neskutečně plýtvá. Často se kvůli pitomým getterům a setterům porušuje Déméteřin zákon.

Téma se jmenuje "Zapouzdření php kódu". Gettery a settery zapouzření porušují úplně stejně jako veřejné atributy.

[Lucius]

settry nic neporusuji - ty jsou k tomu urcene - proste zpristupnite pres metody ty vlastnosti objektu ktere maji byt pristupne z vnejsku a jsou pristupne jen timto jednim zpusobem - ten vas __set nedela nic jineho, je to jen jeste jedna vrstva nad settery - tak jak to pouzivate tak je to principialne vlastne neco jako factory

slozitejsi v tom ze implemetuje vice interface ...

[Kit]

Už jsem psal, že nepoužívám ani jedno z toho. Přečti si to ještě jednou a pořádně.

[Lucius]

tak jak pracujete s nejakym objektem? nepouzivate public metody,property ani __set, tak jak takovemu objektu posilate zpravy ... ?

[Kit]

Používám public metody, ale nejsou to gettery ani settery, protože jejich název (sloveso) říká objektu, co má udělat. Není odvozen od názvu atributů (podstatná jména) a proto se nedá označit jako setter.

Kdyby každý objekt měl jinou sadu atributů, nemohl bych používat polymorfismus.

[Lucius]

takze vam jde vlastne jen o konveci pojmenovani, proto radeji rikam rozhrani a nemusi se pak vest zadna debata - a kazdy at si pojmenovava, jak mu je libo, jak se dohodnou v projektu

[Kit]

Správné pojmenování objektů, atributů, rozhraní a metod je v projektu klíčové. Jak někdo začne používat maďarskou notaci (předpony get-, set-, I-, apod), je to cesta do pekel.

[Ivan Nový]

No není to přesně totéž. Například porovnejte postupy objekt->udělejNěco(kdy) oproti objekt->datum = kdy a objekt->udělejNěco(). Druhý způsob pak vede na uvažování stylem, získat datum uděláníNěčeho a ne místo toho metody, objekt->získejVýsledkyPosledníhoUděláníNěčeho(). A tím se vnitřní implementace objektu dostává do vztahů mezi objekty a znesnadňuje údržbu, protože nakonec musíte programovat vazby mezi objekty. A ty musíte pracně hledat. Naproti tomu vám metoda získejVýsledkyPosdledníhoUděláníNěčeho, vrátí jednoznačný výsledek, který si stačí vypsat a nemusíte jeho strukturu nikde složitě mezi různými zdrojovými soubory hledat. Například.

[Josef Kufner]

Jo, to máš pravdu. Naneštěstí dosti často však je nejlepší vystavit nějaké atributy/properties a pak pár metod, které s nimi něco dělají. Například třída pro odesílání mailů potřebuje nastavit předmět, odesílatele, příjemce a podobně, ale jak to uloží uvnitř už je na ní.

[Kit]

mail($to, $subject, $message);

není třída, ale funkce pro odesílání mailů se třemi (i více) parametry.

[Josef Kufner]

Tohle je značně nepraktické. Jak si poradíš s multipart zprávami, vloženými obrázky, BCC a CC adresáty, datem odeslání, Reply-To, …

[Kit]

Mohu přidat ještě čtvrtý parametr s objektem, který může obsahovat mj. i CC, BCC, datum, ... Kromě toho proměnná $message může být objektem, ve kterém bude multipart zpráva s vloženými obrázky.

[Josef Kufner]

Pokud ten jazyk neumí pojmenované parametry, tak z toho bude velmi brzy guláš. Tohle je právě ten případ, kdy obyčejný setter je mnohem lepší, neboť umožňuje objekt postupně nakrmit daty a pak mu teprve říct, aby něco dělal.

[Kit]

Tohle je zrovna případ "na hraně". Jak bys pomocí setterů nastavil dva CC: , tři BCC: a čtyři přílohy? Všimni si, že mám skutečné parametry sémanticky pojmenovány, guláš z toho nebude. Pojmenované parametry nejsou potřebné, protože už své jméno mají.

[Josef Kufner]

Parametry pojmenované nemáš, guláš v tom bude tam, kde metodu voláš.

Více adres můžeš předat jako seznam, nebo ten setter bude adder – můžeš mít obojí, záleží na kontextu.

[Kit]

Je tak nezbytně nutné, abych měl v kódu pleonasmy typu

mail(to:$to, subject:$subject, message:$message);

?

[Josef Kufner]

Pokud máš parametrů spoustu a mají nastaveny defaultní hodnoty, tak je to jediná šance, jak to učinit čitelné. A protože to je příliš zvrhlé, používají se properties a settery, kterými se data předají postupně a pak se teprve zavolá ta metoda.

[Sten]

Pro posílání mejlů bych použil factory

[Kit]

Pokud mám v PHP spoustu parametrů, tak si jejich pojmenování mohu nasimulovat slovníkem. Nejeví se mi to zvrhlejší než properties a settery. Sice to nevypadá příliš objektově, ale je to přehledné a funkční. Malá ukázka:

$config = array(
    'dsn' => "mysql:host=localhost;dbname=test",
    'user' => "username",
    'pass' => "1234",
);
$db = new MyPDO($config);

BTW: V reálu to mám trochu odlišně, tohle je zjednodušené kvůli snazšímu pochopení.

[Sten]

V reálu to mám trochu odlišně, tohle je zjednodušené kvůli snazšímu pochopení.

Heslo je jiné?

[Kit]

Myslel jsem si, že do toho někdo bude rejpat. Jiné je jméno databáze, uživatele a samozřejmě i jeho heslo. Vlastně tam v reálu nemám ani to klíčové slovo array - místo něho tam je parse_ini_file(), aby se přístupové údaje k databázi nedostaly do repozitáře.