Milyen feladatoknál használnak OO PHP-t? Tudnátok példákat mondani?

Bárhol. Például az adatbázis (alig várom, hogy az amatőrök nekiálljanak károgni, hogy "ez hülyeség"). Ennek részleteibe itt most nem mennék bele.

Amikor az ember szoftvert fejleszt, nagyon fontos, hogy a különálló feladatokat, legyen az a business logic része, vagy technikai dolog, el kell szeparálni egymástól. Ez minél jobban sikerül, annál jobb lesz a szoftver (kissé sarkítva, de nagyon igaz). Ebben az OOP a legjobb. Objektumorientált környezetben olyan hatékony absztrakciókat lehet létrehozni, amelyek procedurális megoldással nemigen lehetségesek. Az ún. "separation of concerns" desing principle -t erősen támogatja az OO, ami elengedhetetlen komoly, nagy rendszerek elkészítéséhez.

A magasfokú átláthatóság és modularitás által nyújtott előnyök mindenhova "odavalók" - Ha a "legjobb" elérhető, miért érnéd be a "szódával elmegy" -gyel?

OO esetén nem egy konkrét algoritmusban gondolkodsz, hanem rendszerben, és olyan egységekben, amelyek a rendszeren belül egy adott szerepet töltenek be.

A példádnál maradva, a következő egy lehetéges megoldás:

- Article osztály (cikk).

- ArticleController osztály. A konkrét requestek kiszolgálására ő fogja össze a többi részegység működését.

- ArticleDAO osztály. Ő felelős a lekérdezések megkomponálásáért.

- Database osztály. Ő felelős a konkrét adatbázis-kezelésért. (A beépíttett PDO osztály kiváló megoldás).

- Egy view template. Ő szinte kizárólag HTML. Nincs egyéb dolga, mint a konkrét megjelenést tartalmazni.

Így egy robosztus és rugalmas alkalmazást kapsz.

A kontrollernek legyen mondjuk egy showArticleList metódusa. Meghívja az ArticleDAO -t (ez így nem túl szakszerű, de a példához megteszi), amaz pedig egy Article példányokat tartalmazó listával válaszol. Ezt a kontroller lepasszolja (pl include) az article list view template -nek, aki eldönti, mi és hogyan jelenik meg a listán, pl.

<!-- itt már nem dolgozunk az adaton, csak megjelenítjük -->

<ul class="articleList">

<?php foreach($articles as $article): ?>

<li><?php print($article->title); ?></li>

<?php endforeach; ?>

</ul>

Valahogy így. Persze, illik ezt jobban átgondolni, jobban megtervezni, stb, de ezt most egy villámpéldának szántam.

Remélem, nagyjából érthető. Ha további kérdésed van, szívesen megválaszolom.

"készítesz egy cikk objektumot és annak lesznek ezek a tagfüggvényei, hogy ment meg megjelenít meg stb. stb"

Ez azért nem jó, mert sérti az úgynevezett Single Responsibility Principle -t, plusz a mentés/megjelenítés/mittoménmicsodálás nem a business domain része, hanem technikai kérdés.

MVC miatt MINDENHOL.

Az OOP a web esetében egy más módszer mintha elkezdenél spagetti kódot vagy függvényközpontú kódot csinálni.

Az MVC lényege, hogy a kódodat szétbontod 3 részre. (Aki ért hozzá az ne szóljon be, hogy nem pontos a szemléltetés kedvéért mondom így:):

- Adatok kezelése

- Megjelenítés

- Irányítás (azaz ami összehangolja, hogy a megfelelő adatok jelenjene meg a megfelelő helyen).

Az OOP ilyen esetben ott lesz villámgyors, hogy mivel elkülönül a megjelenés, az üzleti logikától, így egymástól függetlenül módosíthatók. Spagetti kód esetén nem tudsz úgy design -t cserélni az oldalon, hogy egy sort se kelljen átírnod a működtető kódban. Pont mint ahogyan mondjuk ha a kiderül, hogy a cikkek kezelésénél be kell húzni +5 új mezőt akkor függvényes megközelítés esetén bővítened kell az edit, az add, a megjelenítő templétet, a mentéssel, a módosítással kapcsolatos függvényeket stb, míg egy modelbe felvehetnél +5 új mezőt, amire figyelve a form objektum mindenhol átírja a saját megjelenését.

Ezt persze megoldhatod függvényekkel is, de:

Az OOP lényege, hogy egymástól elszeparált entitásokat hozol létre, melyek képesek kommunikálni egymással. Egy-egy olyan objektumot sokkal könnyebb hibamentesen debugolva létrehozni, ami például a html tartalomért felelős vagy a hírekért. Jobb esetben a híreknek például a nagyrésze már azzal kész, hogy leszármaztatod a html tartalom objektumból.

Egy-egy függvénykönyvtár továbbá ritkán újrafelhasználható. Lehet vele bohóckodni, de nem lesz olyan hatékony mint az objektum újrafelhasználás, leszármaztatás.

Ismét példa: Ha egy html tartalom editálás van az adminodban akkor ott alapesetben mentésnél csinálsz egy ilyesmit:

if ($edit)

{

adatbazis_parancs('ISNERT INTO mezo1,mezo2,mezo3,mezo4 ...');

}

else

{

adatbazis_parancs('UPDATE ...');

}

Namost ha van egy html tartalmi meg egy hírek modulod is akkor bele fogod égetni ezt a parancsot 2 helyre is. Ha egyszer kicseréled az adatbázis motort postgre -re akkor írhatod át mindenhol. Helyette viszont sokkal szebb megközelítés a

$html->save()

vagy a $news->save();

ahol az objektum magától eldönti, hogy updatel vagy insertel, és ezt nem úgy éred el, hogy a html és a news -ba beleégeted a fenti elágazást, hanem leszármaztatod őket egy olyan model objektumból ami tudja ezt.

Bocsi, tudom h kusza így meg rosszul is magyarázok, de a lényege röviden összefoglalva:

- Sokkal gyorsabb fejlesztés

- Sokkal kompaktabb, újrafelhasználható kód

- Mindig tudod, hogy hova kell nyúlni

- Kevesebb hiba

- Karbantarthatóbb kód

rossz oldalról közelíted meg a dolgot igazából, mert az oop nem abból áll, hogy a spagetti kódba itt-ott egy-egy dolgot oop-vel oldasz meg, hanem ha a teljes kódot oop alapon írod akkor azzal rengeteg időt, energiát és későbbi idegeskedést spórolhatsz meg magadnak. (Persze miután belejöttél)

@Előző: Zöld mancs oda.

A példát ott mondjuk elrontottad, hogy a save/stb (ezesetben CRUD) nem a domain objektum feladata, hanem a DAO/Service rétegé, de alapvetően a szemléltetés jó.