Diskuze: Výhody objektů
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.

Tvůrce

Zobrazeno 50 zpráv z 112.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
OOP je rozšíření myšlenky o znovupoužitelnosti. To co lze napsat procedurálně, lze napsat lépe, rychleji a obecněji v OOP.
ok to cos mi řekl mi dalo stejně jako to motto pod komentářem . Pokud jsem to tedy dobře
pochopil, tak se to pak lépe edituje, když to chci na novou věc?
Je to jedna z výhod. Lépe se systém edituje i doplňuje. Celý objekt pak použiješ vícekrát, s čímž souvisí obecnost objektu. Máš například třídu User.
$user = new User(2);
$data = $user->getData();
echo $data->username;
echo $data->password;
echo $data->email;
$user->signIn("admin", "heslo");
$user->signOut();
Nemyslím, že by to šlo bez objektů tak dobře.
ok ta dvojka mě dost mate. co že to má dělat?
Je to jen taková ukázka. První řádek vezme uživatele s ID 2. Druhý zapíše všechny informace o něm do proměnné $data. Další tři řádky jen vypíší jméno, heslo a email. Další přihlásí uživatele s username "admin" a heslem "heslo". Poslední řádek uživatele odhlásí.
Výhoda objektů je přehlednost.
Třídy ti pomáhají členit celý problém do menších logických celků.
Projekt s 100 třídami, kde každá má 10 metod se udržuje lépe než
projekt, kde máš jen 1000 metod za sebou.
Nevýhoda OOP je ta, že to má nějakou režii, takže je to mírně pomalejší.
Ale to je i funkcionální programování oproti pouhému seznamu instrukcí,
protože musíš ukládat před voláním funkce stavy registrů, pushovat na
zásobník parametry funkcí (místo toho, abys na ně šahal přímo) apod.
ach tááák. takže je to to samý jako
<?php
function vypis_hodnoty ($id)
{
global $db;
$sql = "SELECT ... WHRERE `ID_USER` = '$id'";
foreach ($db->query($sql) as $data) { }
return "$data[1] $data[2] $data[3]";
}
function LogIn ($nick, $pass)
{
global $db;
$sql = "SELECT ... WHRERE `NICK`='$nick' and `PASS`='$pass'";
foreach ($db->query($sql) as $data) { }
if (!empty ($data[0]))
{
$_SESSION ...
return "Login";
}
else
{
return "Nelogin";
}
}
function LogOut
{
session_destroy();
}
?>
OK takže tu máme 2 programy co dělaj naprosto tu samou věc ale jeden je
přes fce a druhý přes OOP. teď mi tedy dejte příklad, kdy budu funkce
proklínat a OOP uctívat. věřím že přeci nějaký rozdíl tam MUSÍ být
tak podle mě se dá všechno napsat jak přehledně i nepřehledně. v tom
teda výhodu necítím. možná ta univerzálnost jak tady se zmiňovala. ale
upřímě nevím, co si mám pod tím přímo představit
Ano, psal jsem, že vše se dá napsat procedurálně i objektově.
Nezaručuju, že budeš OOP uctívat, ale zkusím to.
Vezmu si třeba tento řádek:
$sql = Database::oneResult("SELECT ... WHERE `NICK`=? and `PASS`=?", array($nick, $password);
Zapomněl jsi na ošetření proměnných. PDO ti to udělá automaticky. Asi
jsi si všiml i větší přehlednosti jakožto "knihovny". Všechny třídy se
také dají použít později v jiných projektech. Můžeš použít třídy
jiných a snadno je zakompentovat do své aplikace, to by asi v procedurálce
nešlo. Máš tu také už
zmíněnou snadnou údržbu a rozšiřování do budoucna. Můžeš si napsat
třídu na tvorbu miniatur obrázku s obrovským množstvím možností a zbytek
aplikace ani nemusí vědět, co se vlastně děje. Nemusíš znovuvytvářet
kolo, prostě použiješ to, co už existuje.
Chce si to pořádně ohmatat, pak by jsi si našel svoje vlastní výmluvy
proč používat OOP a nutil je ostatním.
Tohle jsi předpokládám asi neviděl: http://www.itnetwork.cz/…oje-softwaru
. Já to stejně
vyzkouším ale vždy je boj když se zkouší něco nového že?... tak až
budu vymýšlet nějakou věc, zkusím to udělat pře OOP. starý zdroje
rozhodně přepisovat nebudu
nn jen jsem koukal na ty nejnovější články co si psal (ohledně tý PHP glaerie - http://www.itnetwork.cz/php/oop )
Tohle by mělo zůstat skryto v modelu. K čemu je ta statika?
Tak si to přečti. Objekt není jen nádoba na funkce, umí zapouzdřovat data, předává se referencí a umožňuje znovupoužívat kód a tvořit architekturu.
Však to byl jen příklad. Vážně? Už zase ta statika? Zdá se že tu máme takový rituál boj Smarty/PHP, Statika/Kit.
Pánové, pánové, přestaňte se hádat, dokud vám nebudu rozumět a
hádat se s váma .
ok tak jsem si to v rychlosti proletěl a zjistil jsem jaký jsou výhody,
ovšem mám pocit že stále se to dá nahradit funkcí (doufám že nevyhraju
nějakýho machra, jelikož jakmile by jste se dozvěděli adresu tak by jste
mě asi ukamenovali ). snad
někdy OOP přijdu na chuť. chce to jen čas a zkušenosti. až to nastane tak
vám napíšu
Pokud si myslíš, že to jde nahradit funkcí, tak jsi to nepochopil.
vždyť to řikám že mě ukamenujete . prostě to snad časem
pochopím. je to stejný jako když jsem se učil v PHP pracovat se
soubory...
Nelíbí se mi, když začátečníkovi ukazuješ věci z OOP, které jsou udělané hnusně a nepřehledně. Ukázky by měly být názorné, aby z nich byla patrná výhoda OOP proti procedurálnímu kódu. Jednoduchost, zapouzdření, elegance, robustnost.
Akimi bude teďka terčem Kitových kamenů, a pak se nemůžeme divit že ty
kostkový chodníky v Hradci nikdy hotový nebudou
To jsou základní kameny pro budoucí programátory a webdesignery. Lítají tady proto, aby ti, kteří tyto diskuze sledují, se mohli svobodně rozhodnout, která cesta jim vyhovuje víc.
Hnusně a nepřehledně? Je to správné použití statiky.
Nelíbí se mi na tom to, že k objektu Database
mají přístup
všechny komponenty aplikace a dokonce mohou s tou databází dělat vše, co je
jim zlíbí. Nakonec zjistíme, že s tou databází smí manipulovat i
webdesigner.
Proč by nemohli mít přístup všechny komponenty? Webdesignér se stará o HTML, nechápu proč by měl volat třídy. Vůbec by do {} neměl sahat.
Koder se stará o HTML, webdesignér se stará pouze o návrh ...
Pardon, dobře. Ale princip je stejný.
Já jenom celou dobu přemejšlel, proč by sakra grafik měl lízt do
jakýhokoliv kódu, zmát jsi mě
K tomu přístupu k databázi - bezpečnost. Není nijak extra bezpečné,
když můžeš přistupovat do databáze odkudkoliv a dělat s ní cokoliv
To lze přece ošetřit. Je to stejné, jen kratší než zápis new, ten taky můžeš vyvolat všude.
Stačí to mít ošetřený. No nic, já už jsem z unavený z pořád té
samé konverzace...
Spíš jde o to, že statický a přístupný by měl být objekt, který bude mít přístup k databázi a bude tahat a přepisovat data která chceme a jak chceme pomocí pár metod.
Do databáze má mít přístup pouze Model a nikdo jiný. Když uděláš databázi jako statický objekt, tak k ní bude mít přístup i ten grafik. Stačí, aby ti útočník nabořil kteroukoli část aplikace a data budou jeho.
Bral jsem to spíše jako ukázku, ale budiž. Však od toho jsou modely, který
jsem sem teď nechtěl přidávat, akorát by to zesložitilo to, co jsem chtěl
vysvětlit.
Nechápu ale, proč by kodér měl ve svým zelí volat třídy. V aplikaci by neměli být díry. Každá se musí ošetřit, všechno musí být zalepené aby nedošlo k ničemu, počítaje i ty nejmenší změny. A to u každé aplikace, takže nevidím rozdíl.
Nové ovladače databází už ani staticky není možné použít. Hlásí to jako chybu.
A to je správně. Už po několikátý tu píšu, že jsem to napsal jako ukázku náhrady za model. Nechtěl jsem to ztěžovat. Jako by to tam nebylo.
Díru jako vrata? Řekni mi konkrétní příklad, kde by to bylo nebezpečné.
Určitě by byl nějaký způsob, kterým by se to dalo využít, tomu věřím. Také neříkám, že je to nejlepší způsob. Ale pro ukázku, kde není ukázaný zbytek aplikace je to správný způsob.
Ono to funguje tak, že všechno, co jde procedurálně, jde udělat i objektově. Proto ti připadá, že je to stejné. Jenže co jde objektově už procedurálně neuděláš, musíš to napsat jinak a přijdeš o určité výhody. Objekty na procedurální programování navazují a rozšiřují ho, není to tedy něco úplně jiného, je to užitečná funkcionalita k těm tvým funkcím navíc.
To se mi nezdá, leda že by nějak dostal svoji šablonu do systému, ale to už si tam může dát stejně svůj model. Nenapadá mě žádné bezpečnostní riziko.
Souhlasím. Mě už procedurální programování nepřipadá nikterat hygienické. S přibývajícími verzemi PHP se taky většina modulů pomalu přesouvá na OOP, i když myslím, že PHP funkce ještě chvíli zůstanou...
Jsme se zrovna s Drahomír Hanákem bavili, že je to PHP už fakt pěkný jazyk, jen si s sebou táhne ten neobjektový balast. Zdá se to ale verzi od verze lepší.
Nejsem žádný hacker, ale trošku jsem se nad tím zamýšlel a přidal k tomu trochu znalostí z C++ a jediný problém ochrany by byla statická doba trvání. Jelikož je objekt alokován už při načtení aplikace do paměti, jeho adresa se nemění. Další věc je to, že (alespoň mi to tak zatím vždy vyšlo) adresy proměnných statického objektu jsou více méně u sebe, takže by mělo poté snáze projít a získat jejich hodnoty. Ale nevím jestli mám pravdu. Zvlášť když je to PHP -> interpret.
Zobrazeno 50 zpráv z 112.