ugrás a tartalomhoz

Feltétlenül szükséges PHP 5-ben objektumokat használni?

NetBandita · 2006. Már. 16. (Cs), 20.25
Sziasztok!

Kezdő PHP tanonc vagyok, az ismereteimet a 'Tanuljuk meg a PHP5 használatát 24 óra alatt' című könyvből szedem. A lényeg a lényeg, feltétlenül szükséges PHP-ben objektumokat használni? Egy haverom azt mondja, hogy felesleges, de szeretném a megerősítéseteket kérni. Biztos nem véletlenül kerültek be, ha értelmetlen lenne.

Köszi a választ!
NetBandita
‹ Űrlapfeldolgozó oldal nem megy tovább Böngésző vs php formküldés ›
 ■
1

Nem szükséges

mefi · 2006. Már. 16. (Cs), 20.39
Feleslegesnek azért nem mondanám, de nem kötelező.
2

De hasznos

Edit · 2006. Már. 16. (Cs), 20.53
Elméletileg bármit meg lehet írni spagetti-kódban. Gyakorlatilag már néhány száz sor után kezelhetetlenné válik a kód.

Én is féltem tőle, de valójában sokkal könnyebb, mint a spagetti. Főleg, ha már mások megírták előtted, neked csak használatba kell venni...:)

Nagyon hasznos volt Harry Fuecks The PHP Anthology - Object Oriented PHP Solutions c. könyve. Az első fejezet egy kicsit sokkoló (polimorfizmus, miegymás), de utána nagyon élvezetes - már ha nem perverzió ezt mondani egy PHP-könyvről.
35

!$oop != $spagetti

Hodicska Gergely · 2006. Már. 19. (V), 22.30
Szia!


A spagetti kód az azt jelenti, hogy a HTML és a PHP keverve van. Ezt megteheted akár OOP kód esetébne is, de abszolút nem sajátja a struktúrált megközelítésnek.


Felhő
39

Hoppá...

Edit · 2006. Már. 20. (H), 00.31
...igazából egyikünknek sincs igaza. Itt van például a Wikipedia leírása. A többi 20 forrás amit megnéztem kb. ugyanezt mondja. Tehát nem azt jelenti, hogy struktúrált, és nem azt, hogy HTML és PHP mix, hanem azt, hogy "tekereg".

További tésztás kifejezések a GNU Project oldalán...:)
42

PHP-ra vonatkoztatva

Hodicska Gergely · 2006. Már. 20. (H), 11.18
A linkek, amiket küldtél nem kifejezetten PHP-ra vonatkoznak. PHP esetében viszont ez a szóhasználat azt jelenti, amit korábban írtam, legalábbis a ebben az értelemben használják.


Felhő
3

A könyved...

-zsolti- · 2006. Már. 16. (Cs), 21.07
...előző részében (PHP4 24 óra) volt egy olyan mondat, hogy az OO-ba mindenki beleszeret, aki egyszer ráérez az ízére. Nos, te még nem érezhettél rá, ezért kérdezed :) Valamint feltehetően a "haverod" sem készített még vendégkönyvnél komolyabb dolgot, ha úgy gondolja, hogy felesleges. Persze meg lehet érteni, nekem is van struktúrált tervezésű portálam. De utólag belenézve a kódjába: kiábrándító, és mostmár mindenképpen OO.
12

Igen...

NetBandita · 2006. Már. 16. (Cs), 23.32
...ez a mondat most is szerepel benne. :) Az OOP-vel foglalkozó fejezetet/fejezeteket nem tartom a legegyszerűbbnek, ezért nem kis vigyorral az arcomon ugrottam át, miután a haverom közölte ezt az infot. Többször futottam neki, de nem állítom, hogy teljes egészében átlátom. Osztom azok véleményét, akik azt mondják, hogy a gyakorlat teszi a mestert. :)
14

FPDF

Edit · 2006. Már. 17. (P), 00.01
Többször futottam neki, de nem állítom, hogy teljes egészében átlátom.

Az FPDF könyvtárat nagyon tudom ajánlani ismerkedéshez Nem kell hozzá semmit telepíteni, és a végeredmény látványos. Egy olyan osztály, ami valami nagyon konkrét, kézzelfogható dolgot produkál, az elején sokat segíthet a megértésben.

Csak letöltöd az fpdf.php fájlt, be-include-olod, és már kezdhetsz is vele dolgozni. Jó bevezető tutorialok vannak hozzá, és sok bővítmény szkript. A PDF készítési ismeret pedig sokszor fog még jól jönni.

Másik jó választás a PEAR HTML_Quickform, ha lehet, még egyszerűbb: HTML-t, valamint validáló PHP és Javascript kódot produkál. Csak egy kicsit macerásabb vele a kezdés, be kell üzemelni előbb a PEAR-t.
4

nekem sem jött be

Anonymous · 2006. Már. 16. (Cs), 21.12
de mennyivel hatékonyabb oo-ban programozni? én is írok minden lépésnek egy külön függvényt, amiket kommentálok is, így egy régebbi bonyolultabb forrást is percek alatt átlátok. valahogy nekem sem állt rá az agyam, attól, hogy berakok egy "class"-t(képletesen), én nem éreztem sokkal többnek a programom...:)
5

oo

winston · 2006. Már. 16. (Cs), 21.34
az, hogy oo programozol, az nem arról szól, hogy "beleraksz" egy osztályt. az még hagyományos, struktúrált programozás, csak használsz egy új adatfajtát. (kapsz az int, a boolean, stb. mellé egy újat, bár kissé bonyolultabbat, saját függvényekkel) az oo programozás igazából arról szól, hogy a program egész felépítése más, objektumokra épül. erről órákat lehetne írni, de ezt itt inkább nem. Szerintem fogj egy könyvet, legyen vár php, c++, java, vagy bármely oo képes programnyelv komolyabb könyve, és olvasd el az oo részt. akkor majd megérted, átlátod, és mérlegeled, hogy fel vagy e már készülve rá, illetve elég nagyívű e a projekted ahhoz, hogy használd.
6

Erről van szó

Edit · 2006. Már. 16. (Cs), 21.37
de mennyivel hatékonyabb oo-ban programozni? én is írok minden lépésnek egy külön függvényt

Na ez az. OOP-vel nem kell írnod semmit. Már minden problémát megoldottak helyetted, neked csak össze kell legózni. Pl. egy szokványos PDF oldal generálása csak 15-20 sor, és egyiknek a megírásához se kell több, mint 3 agysejt...:)

Továbbá szép. És hát egyszer élünk, ez is egy szempont.
7

oo

winston · 2006. Már. 16. (Cs), 21.40
azért az oo nem erről szól. az oo az egy programozási szemlélet, igaz nagy előnye a könnyebb csatlakozás a külön rétegek között.
8

Az OO azért nem ez...

-zsolti- · 2006. Már. 16. (Cs), 21.59
...hiszen azokat az osztályokat, osztálykönyvtárakat is meg kellett írnia egyszer valakinek. Való igaz, hogy talán pl. pusztán PEAR csomagokból is "össze lehetne legózni" akár egy komplett portálrendszert, de attól én még nem biztos, hogy magamévá tettem az OO szemléletet.
9

Természetesen...

Edit · 2006. Már. 16. (Cs), 22.51
...de én konkrétan a 4. hozzászólásra reagáltam, ahol Anonymous kétségeit fejezte ki a hatékonyságot illetően.

Egyébként azt hiszem, hogy mire valaki összelegóz egy portálrendszert, valószínűleg a szemléletből is ragad rá valami. Már maga az, hogy látjuk, mi megy be és mi jön ki, rávezeti az embert alapvető felismerésekre a belső folyamatokról. Még azt is megkockáztatom, hogy "civil" másképp nem is fogja megérteni, csak úgy, hogy előbb elkezd legózni, aztán egyre lejjebb ássa magát a kódba. Lehet persze, hogy programozó egyetemen ez szentségtörés. A Harry Fuecks könyv azért volt jó, mert nem misztifikálta túl a dolgot, konkrét megoldásokat mutatott be gyakori problémákra.

The emphasis this book places on taking advantage of reusable components to build your PHP Web applications reflects another step away from the focus of many current PHP-related books. Although you won't find extensive discussions of object oriented application design, reading ... from cover to cover will, THROUGH A PROCESS OF OSMOSIS, help you take your PHP coding skills to the next level...

Kiemelés tőlem.

Na de hogy valami konkrét dologgal is foglalkozzunk, ha valaki tud jó magyar nyelvű bevezetést az OOP-ba, itt az idő, hogy megossza velünk.
10

oo sokadszor

winston · 2006. Már. 16. (Cs), 23.03
a "civil" nem tanul oo-t. aki már eljut odáig, hogy képes oo-ban tervezni, és megvalósítani, az legalább valamilyen szinten programozó. aki összelegóz valamit oo classokból az nem (feltétlenül) érti, ehhez definiálni kéne a projekt méretét. attól még nem tud valaki oo programozni, ha elévágnak 5 ojjektumot, hogy illeszd össze öcsém. "valahogy" nem nehéz összeilleszeni. ahhoz kell az, hogy megtanulja kialakítani a megfelelő struktúrát, mind az objektumokon belül, mind pedig azok között. az amúgy nem hatékonyságnövelő, hogy összeollóz valamit, legfeljebb munkatempó növelő.

(megj: a legtöbb informatikus / programozó, aki ezt a pályát választja, az már az előtt ismeri legalább az oo alapjait, hogy a "programozó egyetemre" menne, és nagyon különböző módokon és sorrendben tanulják meg. ott már csak a miheztartás végett adják le az alapokat. még egy apróság: tudom, hogy nem erre ment ki a dolog, de egyetemi szinten nem programozót szoktak képezni, hanem informatikust)
11

Olló

Edit · 2006. Már. 16. (Cs), 23.09
az amúgy nem hatékonyságnövelő, hogy összeollóz valamit, legfeljebb munkatempó növelő

Régen volt már a Közgáz, de úgy emlékszem, hogy hatékonyság = eredmény/munka. Ha a munka csökken, a hatékonyság növekszik...:)))

egyetemi szinten nem programozót szoktak képezni, hanem informatikust

Én meg történetesen "marketing-kommunikációs üzemgazdász" vagyok - csak meg ne kérdezd, mi az...:)))))))))))
13

hatékonyság

winston · 2006. Már. 16. (Cs), 23.50
hatékonyság: az ilyenekkel az eredmény (minőség) is romlik, hisz ha nem fordítasz időt áttanulmányozni, és nem ismered az objektumot, akkor nem fogod tudni rendesen kihasználni. ha áttanulmányozod, akkor is igazodnod kell hozzá a többi (máshonnan szedett, máshogy tervezett) modullal, és kevesebb időt nyersz. ha pedig még testre is szabod, akkor megint több idő elment és az eredmény/munka érték megint nagyjából ugyan annyi. így leginkább a programozó tudására esik a hangsúly, hogy mennyire dolgozik gyorsan, (munkaidő) és milyen szinten tud programozni (eredmény), mennyire képes a saját hatékonyságát belevinni a munkába, és erre magától értetődően a saját fejlesztésben van lehetősége. Persze csak olyan programozó esetén érdemes, aki érti a dolgát. Értsd: minél jobb a munkaerő, annál jobban el lehet szakadni az előre elkészített dolgoktól. Mit akartam ebből kihozni? A hatékonyság a programozón múlik, nem a munkaidőn. szvsz (közgázból mondjuk gyenge vagyok, mert soha nem volt herótom hozzá)

(szakma: én "műszaki informatikus mérnöknek" készülök ;))
36

naiv

Hodicska Gergely · 2006. Már. 19. (V), 22.38
Na ez az. OOP-vel nem kell írnod semmit. Már minden problémát megoldottak helyetted, neked csak össze kell legózni.

Ez NAGYON naiv megközelítés/hozzáállás. OOP programozás az nem abból áll, hogy használsz objektumokat.

Pl. egy szokványos PDF oldal generálása csak 15-20 sor, és egyiknek a megírásához se kell több, mint 3 agysejt...:)

És ugyanennyi sor lenne egy struktúrált PDF könyvtár használata esetébne is.


Felhő

u.i. Nem az OOP ellen szóltam, csak dobálózzunk az ilyen kijelentésekkel óvatosan.
40

Tekereg

Edit · 2006. Már. 20. (H), 00.48
Ez NAGYON naiv megközelítés/hozzáállás. OOP programozás az nem abból áll, hogy használsz objektumokat.

Erre már Dúalon is ráugrott, de ha elolvasod a szálat, láthatod, hogy itt nem az OOP programozásról volt szó, hanem a hatékonyságról.
És ugyanennyi sor lenne egy struktúrált PDF könyvtár használata esetébne is.

A 15-20 sor megintcsak a hatékonyságra vonatkozott (ti. hogy nem neked kell megírni). Persze ha létezik struktúrált PDF könyvtár, azt is nyilván elég könnyű használni - elméletben. Gyakorlatban egy PDF könyvtár értékét az extrák adják (az FPDF-hez van vagy 70 féle) - ezt már csak OOP-vel lehet kezelhetővé tenni.
44

OOP - hatékonyság

Hodicska Gergely · 2006. Már. 20. (H), 11.38
Erre már Dúalon is ráugrott, de ha elolvasod a szálat, láthatod, hogy itt nem az OOP programozásról volt szó, hanem a hatékonyságról.

Amilyen példákat eddig felhoztál, azok többsége nem aknázza ki az OOP-t lehetőségeit, hogy azokat ne lehetne struktúráltan is megvalósítani. Szerintem is könnyebb OOP (nekem erre áll rá az agyam), de ettől függelenül ne mondjuk olyan (kicsit közhelyszerű) dolgokat, amik nem állják meg a helyüket.

Annó Carnában csináltam egy kis belső oktató anyagot OOP újrhasznosítás (~hatékonyság) témájáról az OOP vs struktúrált programozás vionylatában, ha lesz időm és meg van még, akkor felnyomom ide.


Felhő
27

hoppaaa

toro · 2006. Már. 18. (Szo), 10.26
Na ez az. OOP-vel nem kell írnod semmit. Már minden problémát megoldottak helyetted, neked csak össze kell legózni.


Es akkor jon az, hogy kapok egy "profi" siteot, ahol ket PEAR konyvtar van lerakva, ket FCK editorral, 4 helyen a config, a tobbnyelvusites abbol all, hogy 3szor teszik le az oldalakat _hu, _de, _en vegzodesekkel, a menupontok dinamikusan szerkesztheto szovegehez kulon kulon adattabla van rendelve stb.

Na es akkor jon a fonokom, hogy ugyan mar legyek kedves itt ott modositani, es nem erti miert ver ki a viz.

Nezetem szerint eloszor tanuljon meg a valakozo szellemu programozni, lassa at a feladatot, tanuljon meg tervezni(!), atlatni a problemat, tanulja meg, hogy a programozas nem ott kezdodik, amikor mar le tudok irni egy echo "hello word" utan egy new szocskaval egy 15 sorost!

Amikor ugy erzi mar magatol, hogy a linearis programok nehezen jonnek ossze (nem lehet goto-zni, mint a BASICben), akkor el lehet kezdeni strukturalni, es ha mar az is keves, mert ismet nehezen atlathato a kod, akkor nezzunk utana mivel lehetne meg jobban egyszerusiteni a sajat munkankat.

Ugy gondolom, hogy ha valakinek nehez az objektumok hasznalatanak megertese, az azert van, mert nincsen ra szuksege! Felesleges kovetelmeny lenne ennek elenere raszoritani valakit az OOPre.

Gondoljuk meg mi lenne, ha kovacs tanoncnak nem egy kis kalapcsot adnanak eloszor a kezebe, hanem egy 10 kilosat, vagy odaallitanak, a gozkalapcs melle, hogy forgassa az izzo vasat. A 10 kilost nem birna el, a nagy pedig kiverne a kezebol az anyagot, akar halalos sebet is ejtve.

Kezdjen mindenki a kis kalapaccsal, azzal is lehet szep dolgokat alkotni!
28

OK

Edit · 2006. Már. 18. (Szo), 11.06
Ugy gondolom, hogy ha valakinek nehez az objektumok hasznalatanak megertese, az azert van, mert nincsen ra szuksege!

Igen, ezzel egyetértek. Ahogy most visszagondolok, az elején én is azzal küzdöttem, hogy nem tudtam, mi a kérdés, amire az OOP a válasz.
29

Mi a kerdes

Anonymous · 2006. Már. 18. (Szo), 13.50
Igen ez nalam is igy volt. Nem kell eroltetni, mikor kell majd akkor leesik, hogy mirol van szo. Mondjuk kapsz egy nagyobb melot, akkor rajossz mindenre mert a problema atgodonlasa ravezet a kerdesre, magad fogod feltenni, hogy kene valami, ami ugy all ossze, hogy. Aztan mar meglesz a valasz is: OO.

csab.
30

Kör

Edit · 2006. Már. 18. (Szo), 14.22
Tehát az OOP megértéséhez kell egy nagyobb feladat, ami megérteti, mire való. Viszont nagyobb feladatot az kap, aki érti, mire való az OOP...:)

Személyes tapasztalat: OOP-t nekem szinte soha nem kell írni. Olvasni viszont minden nap. Ha más nem, Javascript.

Aki nem tud OO könyvtárakat olvasni, használni, az már eleve nem kap munkát. Amennyire én látom.
31

Vagy...

NetBandita · 2006. Már. 18. (Szo), 14.35
...aki magának jelöl ki komolyabb feladatokat. :)

Véletlenül JavaScriptet is tanulok szinkronban a PHP-vel. Egyelőre csak a w3schools JS basic-et vittem végig, ahol még objektumokról nem esett szó. Az OOP szemlélet elsajátítására az jó alap?
32

Nem ajánlom

Edit · 2006. Már. 18. (Szo), 14.51
A JS könyvtárakat a böngészők DOM motorjára írják, ami pl. az IE esetében elég vacak. Tehát időnként csak azért kell osztályokat írni, mert másképp nem lehet az IE-t rávenni a helyes működésre - és nem azért, mert a feladat szervezése indokolja.

A múlt héten kellett csinálnom egy tabos belső navigációt, ahol a tabok div horgonyokra mutatnak. Ezt találtam hozzá: DomTabs. Egy csúnya Javascript osztállyal oldotta meg, azt mondtam, megcsinálom szebben. Mit mondjak - nem csináltam meg. Az összes komoly JS könyvtár tele van ilyen kényszermegoldásokkal. OOP-nek OOP, de nem érdemes ezeken tanulni, csak összezavar.

Az egyik Yahoo JS fejlesztő mondta nekem, hogy a PHP értelmezőre minden óvodás tud OOP-t írni - böngészőre fejleszteni, az már valami...:)
37

Kötekedés ;)

Hodicska Gergely · 2006. Már. 19. (V), 22.51
A JS könyvtárakat a böngészők DOM motorjára írják, ami pl. az IE esetében elég vacak.

Ebből a két állításból kettő elég gyenge lábakon áll. Kíváncsi lennék, hogy mire alapoztad.

Az egyik Yahoo JS fejlesztő mondta nekem, hogy a PHP értelmezőre minden óvodás tud OOP-t írni - böngészőre fejleszteni, az már valami...:)

Ez így ebben a formában elég komolytalan állítás. OOP szemlélettel megfogalmazni egy problémát az nyelv független dolog.


Felhő
41

DOM

Edit · 2006. Már. 20. (H), 01.21
Ebből a két állításból kettő elég gyenge lábakon áll. Kíváncsi lennék, hogy mire alapoztad.

Nem értem, az első állítással mi a gond. Légyszi homályosíts fel..:)

A második állítást széleskörű és mélyreható személyes tapasztalatokra alapozom. A böngészők általában jól kezelik a, nevezzük így, mozgásokat (kinyílik, becsukódik, eltűnik, megjelenik), de például stílust csak az FF hajlandó rendesen változtatni, akár "direktben", akár a class attribútumon keresztül. A definíció szerint a DOM egy
platform- and laguage-neutral interface that will allow programs and scripts to dynamically access and update the content, structure, and style of documents.

A content és a structure oké, a style viszont vacak, egyébként - meglepő módon - Operában is.

Ez így ebben a formában elég komolytalan állítás. OOP szemlélettel megfogalmazni egy problémát az nyelv független dolog.

Elnézést, tévesen idéztem a Yahoo-s egyént. Nem konkrétan az OOP-ről beszélt, hanem úgy általában a JS fejlesztésről - ami szerinte nehezebb, mint a PHP, a böngészők miatt.
43

re: DOM

Hodicska Gergely · 2006. Már. 20. (H), 11.33
Nem értem, az első állítással mi a gond. Légyszi homályosíts fel..:)

Csak túl általános, annyi. Rengeteg olyan cucc van JS-hez is, aminek köze sincs a DOM-hoz. Crypt könyvtár, nyelvi elemeket kibővítő cuccok vagy akár AJAX kommunikációt megkönnyítő könyvtár.

de például stílust csak az FF hajlandó rendesen változtatni, akár "direktben", akár a class attribútumon keresztül

Olvasd el a saját definíciód. A DOM a felületet biztosítja, de az nem az ő hibája, hogy a stílusokat az IE nem kezeli jól. Ez nem a DOM feladata.

hanem úgy általában a JS fejlesztésről - ami szerinte nehezebb, mint a PHP, a böngészők miatt

Még ebben a formában sem mondanám, hogy egyet értek vele, mert így meg nem igazán tekinteném összehasonlíthatónak a kettőt. Melyiket nehezebb megcsinálni: egy modularizálható CMS rendszert, vagy pedig egy Gmail-t? ;)


Felhő
46

DOM?

Edit · 2006. Már. 20. (H), 12.19
Olvasd el a saját definíciód. A DOM a felületet biztosítja, de az nem az ő hibája, hogy a stílusokat az IE nem kezeli jól. Ez nem a DOM feladata.

Nem akarom elvinni a topikot DOM irányba, úgyhogy csak jelzésszerűen néhány IE hiányosság, amibe állandóan belefutok: cssRules[], deleteRule(), insertRule(), getPropertyValue(), setProperty() (Főleg a legutóbbi nagyon kellemetlen tud lenni.)

Újraolvasva a topikot, lehet, hogy tényleg félreérthető voltam OOP-val kapcsolatban, de szerencsére helyre lettek téve a dolgok..:) Mindenesetre NetBandita talál néhány könyv linket - remélhetőleg fogja tudni őket használni.

Edit
47

konkrétum

Hodicska Gergely · 2006. Már. 20. (H), 13.53
néhány IE hiányosság, amibe állandóan belefutok: cssRules[], deleteRule(), insertRule(), getPropertyValue(), setProperty()

Na látod, ez így már mindjárt másképp hangzik, mint általánosságban, hogy "elég vacak". Ezek közül az első 3-nak van IE alatti megfelelője, az utóbbi 2-ről nem tudom.


Felhő
33

oo

sayusi · 2006. Már. 18. (Szo), 15.29
Nekem a kollegáim mondták, hogy ha komolyan gondolom ezt az OO dolgot php-ban akkor csináljam úgy, hogy minden objektumokban vagy objektumként létezik.
Mert ha egyszer beleszaladok egy java tanulásba, akkor ott ez lesz.

Igazán még én se értem a lényeget, de a kezdeti agybénuláson már túl vagyok...

Aztán jött a másik kollega és húzott egy párhuzamot az emberei gondolkodás és az OO programozás között. Na így már sokkal könnyebb.
34

Én kíváncsi lennék

NetBandita · 2006. Már. 18. (Szo), 15.55
Érdekelne az a párhuzam, amivel a kollégád élt. Hátha nekem is segít. :)
15

Példa

janoszen · 2006. Már. 17. (P), 00.16
Azt hiszem itt az ideje egy gyakorlati példának.

Tegyük fel, hogy egy HTML kódot akarsz kinyomni a kimenetre. De ugye, mit ad Isten, echo parancsokkal nyomtad ki és ennek következtében a kód úgy néz ki, mint a falra hányt zöldborsó. Szal guszta, na.

Ekkor fogod az én kis kódformázó output osztályomat: (nem kell megérteni!)

<?php
class Output
{
 function Output()
 {
  ob_start();
 }
 
 function flush()
 {
  $this->_content = explode("\n", ob_get_contents());
  foreach($this->_content as $no => $line)
  {
   $this->_content[$no] = trim($line);
  }
  ob_end_clean();
  $this->_processindenting();
  foreach($this->_content as $line)
  {
   if (trim($line) != "") echo($line . "\r\n");
  }
 }
 
 function _processindenting()
 {
  $indent = 0;
  $lastindent = 0;
  foreach($this->_content as $no => $line)
  {
   if ($line != "")
   {
    $blastindent = $lastindent;
    $lastindent = $indent;
    $n = substr_count($line, "<") - substr_count($line, "<!") - substr_count($line, "/>") - 2 * substr_count($line, "</");
    if ($n < 0) $indent = $indent + $n;
    $this->_content[$no] = "";
    
    if (($lastindent == $indent) && ($blastindent > $lastindent))
    {
     $this->_content[$no] .= "\r\n";
    }
    
    for ($i = 0; $i < $indent; $i++)
    {
     $this->_content[$no] .= " ";
    }
    $this->_content[$no] .= $line;
    if ($n > 0) $indent = $indent + $n;
   }
  }
 }
}
?>
És bemásolod egy Output.php fájlba. A fenti kódot semmi szükség érteni. Csak annyit csinálsz ez után, hogy az oldalad generálása előtt és után meghívod az output osztályt:

<?php
 require_once("Output.php");
 $output=new Output();
?>
<!DOCTYPE

spagettikód

>
<?php
 $output->flush();
?>
Feltételezve, hogy a spagettikódodban néha van enter vagy \n és nem írtam el semmit, az eredmény olyan lesz, mint ennek az oldalnak a kódja: http://www.kontenerpiac.hu/

Remélem, ez segített megérteni. Szal az osztályom belső működését nem kell ismerned, anélkül is tudod használni. Azon felül jobb lehetőséget ad a struktúrálásra.

Egyéb szép dolgok:

- private változók/függvények (lásd fent a _processindenting. Kívülről nem tudod meghívni)
- öröklődés:

egy "állat" osztályból örökölheted a macskát és az egeret. Akkor az utóbbiak az előbbi összes függvényével rendelkezni fognak anélkül, hogy külön le kellene programoznod.

stb, stb, stb.
17

php4 és az objektumok

Anonymous · 2006. Már. 17. (P), 09.01
tegyük hozzá, hogy manapság még sokkal elterjedtebb a php 4-es szériája, és ott egy-két apróságot hozzá kéne tenni az osztályodhoz.

hivatalosan az osztály változóit deklarálni kell:

<?php
class Output {
  var $_conntent;
  function Output() {
    ...
?>
gyakorlatilag megy enélkül is, de még így is jól jöhet, hogy megértsd később a kódod.

a másik pedig, hogy
(lásd fent a _processindenting. Kívülről nem tudod meghívni)

nem tudom kipróbáltad-e egyáltalán, de nem igaz. php4-ben nincsenek privát metódusok. az aláhúzásjel nem ér semmit se egy változónál, se egy függvénynél.

gex
25

Jogos...

janoszen · 2006. Már. 17. (P), 20.06
Jogos mindkét megjegyzés. Ezt az osztályt idestova egy fél éve írtam, azóta már egyáltalán nem foglalkozom PHP 4-gyel. Teljesen átálltam PHP 5-re.

A példa célja a bemutatás volt és azt hiszem, annak meg is felelt. Ez az osztály volt éppen kéznél, ami elég egyszerű volt ahhoz, hogy kitegyem.

Mindenesetre tényleg igazad van.
16

Húú...

Anonymous · 2006. Már. 17. (P), 01.22
Nagyon köszönöm mindenkinek a segítséget! Igyekszem feldolgozni mindazt, amit itt olvastam, aztán max. kérdezek - ha nem találom meg a weben vagy a könyvben a választ, persze. :)
18

Konstruktív kritika

ftomi · 2006. Már. 17. (P), 10.32
Szerintem itt nem kellett volna obijektumokat használni: mi lenne ha $this->_content helyett $GLOBALS["_content"]-et írtnál, elhagynád a class-t, és require_once("Output.php"); $output=new Output(); helyett simán Output()-ot írnál? Nem világos az $output object, és a külvilág kapcsolata sem a felületes szemlélődőnek. (Aki lehetsz akár te is egy pár hónap mulva.) A jó classoknál nem kell átnézni a class forrását, hogy megértsd az azt használó program futását. Én ezt úgy oldanám meg, hogy csak simán require_once("Output.php");, amiben lefut magától az ob_start(); egy callback paraméterrel, és így a flusht-t sem kell külön meghívni. Így ha valaki belenéz az oldal php-jébe, nem kell tudnia mi van az Output.php-ban, mert transzparensen ottvan, program futását nem (vagy csak kicsit) befolyásolja. (Főleg csak akkor, ha használnál még ob_startot máshol.) A class-t végülis meghagynám, jó az namespacenek, de static metódusokat és változókat raknék bele, hiszen két példány úgysem lehet az obijektumból.
26

Nem...

janoszen · 2006. Már. 17. (P), 20.08
Hát, hozzátenném, hogy meg lehetne csinálni, de mivel teljesen OO alapú a rendszer és ráadásul ez egy erősen lecsonkított példa, nem hiszem, hogy ez helytáll. Amúgy meg pont az OO bemutatása lett volna a példa.
19

OOP

Dualon · 2006. Már. 17. (P), 14.12
Olvasgatom itt a hozzászólásokat, és nagy szemeket meresztek. Ajánlanám tanulmányozásra a Drupal motorját, amely nem épp osztálygazdagságáról híres, mégis erősen objektum-orientált megközelítésű.
Liebig Zsoltnak súlyosan igaza van.
21

PHP 24 óra

Edit · 2006. Már. 17. (P), 16.40
Ne feledjük, mivel indult a topik: érdemes-e NetBanditának megküzdenie a PHP 24 órás könyv objektumos fejezetével, mert elsőre elég nehéznek tűnik számára.

Hát erre a kérdésre szerintem nem az a jó válasz, hogy inkább nézd meg a Drupal motorját...:)
22

Többeknek, és nem az első hozzászólásra válaszoltam

Dualon · 2006. Már. 17. (P), 18.48
Nem szerencsés félrevezetni valakit, aki még csak most kezdi kapisgálni a dolgokat.
23

Konkrétan?

Edit · 2006. Már. 17. (P), 19.43
Konkrétan mire gondolsz? Félrevezető azt állítani, hogy osztályokat "fekete dobozként" használva, kívülről is el lehet kezdeni az ismerkedést?
24

csak konstruktívan...

winston · 2006. Már. 17. (P), 19.59
szvsz: hát ha nem is félrevezető, mindenesetre messze nem a legjobb alap. de a helyett, hogy ezen vitáznánk: vannak erről relevánsabb írások is, mondjuk a már kiadott könyvek. amit ajánlani tudok: (és amit ma már egy másik topicban is ajánlottam):

-Nyékné G. Judit (szerk): Java 2 útikalauz programozóknak 1.3 (sajna nehéz beszerezni)
-Computerbooks, Együtt könyebb a programozás sorozat: C++
-Peter Moulding: PHP Fekete Könyv

Az első kettő ugyan lényegesen jobb konkrétan az OOP leírásában (a nélkül is érdemes elolvasni, hogy C++-t vagy Javát programoznál) viszont a harmadik meg php... meg persze biztos vannak más jó források is, de én ezeket ismerem úgy, hogy tényleg jók.
45

Objekumorientált szoftverfejlesztés

Hodicska Gergely · 2006. Már. 20. (H), 11.41
A fenti könyvet ajánlanám a témában még.


Felhő
57

könyv

winston · 2006. Már. 21. (K), 22.09
tényleg jó könyv, és a mai könyvárakhoz képest nem is drága (ráadásul az egyik szerző az előadóm, és nagyon érti a dolgát)
20

óvatos oop :) szuper oop :)

virág · 2006. Már. 17. (P), 15.29
Szia,

nem kell objektumokat használni mindenáron. Viszont azért ez sok dologtól függ. :)) A minap pl. kaptunk egy mások által írt CMS-t, amihez modulokat kellett fejleszteni. Az egész forráskódjáról az első benyomásom az volt, hogy a fejlesztője éppen kiszabadult egy "obejktumorientált programozás" kurzusról és elhatározta, hogy ő most valami óriási dolgot alkot és csak OOP-vel, de aztán nem jött össze néki (az én nagy bánatomra, mert szívhatok vele).

Szóval tudás, projekt (méret, típus) dönti el mit használj. Hameg ebből élsz, akkor a projektvezető, tervező :))

Szerintem szuper dolog az OOP, és én nagyon szeretem használni, de nem ennek a módszernek a használatától függ, hogy "spagetti" típusú, avagy egyéb "csúnyácska" állagú forráskódot írsz-e avagy sem. :) Hanem a hozzáálásod... Persze ez nem mentesít a tanulás alól. :)

szép napot!

j.
38

Komoly vicc..

janoszen · 2006. Már. 19. (V), 23.32
Mondok egy viccet, akkor mindjárt meg lehet érteni, hogy mi is az az OO. Ezt a PT tanárom mesélte. Hogy tényleg megtörtént-e, nem tudom.

Szóval, egy cég gyártott a hadseregnek egy helikopter szimulátort. Aztán ezt a szimulátort eladták az ausztráloknak is. De hát mivel Ausztrália, ezért kellettek kenguruk is. Nosza, meg is valósítottak.

Egyetlen hiba volt az elképzelésben, méghozzá az, hogy a kenguru osztályt a katona osztályból származtatták. A szegény pilótatanonc meg csak azon csodálkozott, hogy miért lő rá a kenguru rakétavetővel.
48

-

breakline · 2006. Már. 20. (H), 15.46
Azért az nem teljesen igaz, hogy hosszú dolgokat csak oop módszerrel lehet átláthatóan megírni. A php kimenetének állaga meg maximum esztétikai szempontból lehet jelentőségteljes. Én szivesen használom pl. a függvény orientált (nem is tudom magyarul hogyan mondják) módszert, ekkor mindent függvények csinálnak, és így szépen külön lesz választva a megjelenítés és a motor, nem mellesleg legalább ugyanannyira újrahasznosítható, mint egy oop módszerrel írt program. Egyszer megírsz egy jó filekezelő vagy kereső függvényt, azt utána sok helyen tudod alkalmazni. És könnyen bővíthetők. Persze kinek a pap kinek a papné. :)
És nem szabad elfelejteni, a prog. nyelvek nagyrésze még mindig a függvényekre épül, lásd php manuál, bár programozási nyelvek programozásához nem értek:)


üdv
BL
49

Hehe

janoszen · 2006. Már. 20. (H), 19.54
Kíváncsi lennék, hogy azt a projektet, amin most dolgozom (kb. 100-200 osztály, tervezési fázisban van) hogy oldanád meg OO nélkül. Még OO-van is piszkosul nehéz feladat. Megpróbáltam annó oo nélkül. Keserves kudarcba fulladt.
50

-

breakline · 2006. Már. 21. (K), 02.54
én úgy gondolom, hogy aki írja, az látja át legjobban az adott kódot. De nem csak oo-val lehet segíteni ezt. Pl. megfelelő változónevekkel, tagolással, részekre bontással. Ha esetleg valakinek odaadod a kódod, valószínüleg nem fog egyedül rájönni, melyik osztály mit is csinál, vagy mit hol keressen. Olvastam oo módszertanról, és úgy gondolom, ez is csak egy lehetőség. Nyilvánvaló, hogy projectmunkára a legjobb, de más is van a világon. Persze ha egyszer megtanulod, valószínüleg azt fogod használni. És újabban már mindent ebben írnak, nem mellesleg oo módszerrel lehet a legjobban a nyelvek között "kommunikálni".
De hát autót sem egyféleképpen lehet építeni, nem szabad a kreativitás kárára egy módszert alkalmazni. Tiéd a program, te fejleszted.

Egyébként milyen projekten dolgozol, ha megkérdezhetem? Nem hangzik egyszerűnek:)

üdv
BL
52

Igaz

janoszen · 2006. Már. 21. (K), 11.31
Ez ugyan igaz, de megpróbáltam a függvényeket tagolni, darabolni, de valahol mindig elvesztem. Egyszerűen nem működött.

A projekt, amin dolgozom egy CMS rendszer. Mondjuk, ez így kicsit pontatlan megfogalmazás, de a részletek titkosak, mert számos olyan ötlet van benne, hogy két szóból utánacsinálja bárki, de nagy ötlet, mert még sehol nem alkalmazzák. Szal a helyes megjelölés inkább A cms rendszer. :D Ha minden igaz, szeptemberre végzek vele (6 év fejlesztés!) és akkor lehet megnézni.
53

-

breakline · 2006. Már. 21. (K), 13.01
OFF
6 év az szép! Sőt az igen! Kiváncsivá tettél, ilyen hosszú fejlesztésről még nem is hallottam.
ON
51

Hogy fogtam fel az OO-t

Anonymous · 2006. Már. 21. (K), 11.01
Anno én is gondolkoztam, hogy de jó lenne OO-zni a PHP-ban, csakhogy el se tudtam képzelni, hogy mi az az objektum, meg hogy egyáltalán hogy is akar ez menni. Könyvek garmadája sem segített ezen, mert azok már olyan foglamakat használtak, amiket még szintén nem ismertem, így nem nagyon értettem meg. (mint amikor ANSI C-t tanultam és az első gyakorlaton a mutatóra mutató mutatót adta le a tanár. Mivan???.). Autodidakta módon segítség nélkül, jó magyar nyelvű források híján kicsit nehéz volt belejönni.

Aztán már eljárásorientált fejjel gondolkozva még nehezebb volt. Ezért ez egyik haverom mondott egy ilyet:

C-ben a típus ugyebár megadja, hogy hány byte-on tárolódik az érték, megadja az értelmezési tartományt (vagyis hogy milyen értéket vehet fel) és a rajta végezhető műveleteket. Gondoljunk mondjuk az INT-re és megértjük ezt.

OO-ban tulajdonképp valami ilyemit csinálunk, csak itt a programozó hozza létre a "típust" (osztály), megadja a "felvehető értékeket" (osztályváltozók stb.) és hogy milyen "műveletek" végezhetők rajta (metódusok).

Bár ez a levezetés valószínűleg teljesen hibás, de arra jó, hogy kiindulási pontot adjon az objektum fogalmának megértéséhez. Ha ez megvan, akkor már könnyebben tanulható az egész OO jelenség is, és akkor nem kell ilyet kérdezni, hogy kell-e vagy jó-e vagy hasznos-e. A végén akarni fogod. Önként. És jó lesz :)
54

-

breakline · 2006. Már. 21. (K), 13.04
Én egy Java könyvet olvastam át. Mivel a Java teljes egészében oo-ra épül, így ha azt megtanulod valahogy, utána már menni fog. Ez volt az (vagyis én az első részt olvastam, a második inkább már csak a javat mutatja be):

http://www.kiskapu.hu/index.php?BODY=BookInfo&OP=details&ID=34646&VISIT=1

nagyon hasznos, mert az első könyv fele csak a módszertanról szól, és csak utána kezd bele a Java-ba.

üdv
BL
55

elképzelés

erenon · 2006. Már. 21. (K), 15.36
Én úgy képzelem el a classokat, mint egy olyan tömböt, aminek meghatározott számú indexe van, viszont az adatok felvétel után a megadott függvény szerint módosulnak.
Tegnap kezdem el a "PHP fejlesztés felsőfokon" című könyvet, akkor értettem meg. (legalábbis feltételezem, h értem)
56

egységbe zárás

Hodicska Gergely · 2006. Már. 21. (K), 18.16
Szia!


Ha már így közelíted meg, akkor szerencsésbb az a megfogalmazás: hogy egy osztály egységbe zár egy adott adatstruktúrát, és az azokat kezelni képes függvényeket.
Elképzelheted úgy is, hogy van egy tömböd, ami egy maghatározott struktúrában leír egy valamilyen entitást (dógot). Ha írsz egy ezt kezleni képes függvényeket, akkor mindig át kell adnod azoknak első paraméterként az éppen aktuálisan kezelendő tömböt.
Na egy osztály esetében a példányosított objektum tartalmazza ezt a tömböt, és a kezelő függvényeket ezen meghívva azt éred el, hogy ezek az aktuális példány adataival fognak dolgozni.


Felhő