PHP klausimas: Kada naudojat objektinį programavimą?

Neieškau google straipsnių ar kokių senų komentarų, o noriu sužinoti jūsų nuomonę ir patirtį kuriant interneto tinklapius ir naudojant objektinį programavimą.

• Kodėl naudojat?
• Kokie to privalumai / trūkumai?

Todel, kad jai nenaudoji gaunasi misraine :D

Sakykim, nori integruoti kelis mokėjimo metodus ir žinai, kad abu jie atlieka funkcijas vienodais pavadinimais, bet pačių funkcijų veikimas skiriasi (priklausomai nuo mokėjimo sistemos).

Tuomet: vienas objektas yra PayPal, kitas objektas yra MoneyBookers.

Jei nori sugeneruoti PayPal apmokėjimo formą, gali kreiptis PayPal::createForm() (ar PayPal.createForm() - jei ne statinis metodas), jei MoneyBookers - MoneyBookers::createForm().

Taip gali turėti daugybę klasių, kiekvieną atskirame faile su jai priklausančiomis funkcijomis.

Priešingu atveju turėtum tikrą mišrainę.

Apskritai, kai pradedi objektus naudoti visur, nebesinori nustoti, nes tai tiesiog palengvina programavimą. Bet kokią sistemą gali suskirstyti į objektus ir jiems skirtas funkcijas. Pavyzdžiui: Animal yra objektas, kuris turi funkcijas Animal.eat(), Animal.sleep() ir pan.

Todel, kad jai nenaudoji gaunasi misraine :D

Na, bet juk įmanoma ir gražiai susirašyti funkcijas ir jomis naudotis.

Ir klausimas, ar naudojant objektus kodas veikia greičiau, nei naudojant funkcijas? Ar esmės nėra? Aišku apsirašius klasę, kintamieji visi gražiai matosi, ir metodai, o funkcijomis gyventi gali, kai reikia nedaug ką daryti. Bet būtent kokius darbus atlieki su klasių metodais, o kada nusprendi kad užteks ir funkcijų? Visur juk OOP nenaudosi

Sakykim, nori integruoti kelis mokėjimo metodus ir žinai, kad abu jie atlieka funkcijas vienodais pavadinimais, bet pačių funkcijų veikimas skiriasi (priklausomai nuo mokėjimo sistemos).

 

Tuomet: vienas objektas yra PayPal, kitas objektas yra MoneyBookers.

 

Jei nori sugeneruoti PayPal apmokėjimo formą, gali kreiptis PayPal::createForm() (ar PayPal.createForm() - jei ne statinis metodas), jei MoneyBookers - MoneyBookers::createForm().

 

Taip gali turėti daugybę klasių, kiekvieną atskirame faile su jai priklausančiomis funkcijomis.

 

Priešingu atveju turėtum tikrą mišrainę.

 

Apskritai, kai pradedi objektus naudoti visur, nebesinori nustoti, nes tai tiesiog palengvina programavimą. Bet kokią sistemą gali suskirstyti į objektus ir jiems skirtas funkcijas. Pavyzdžiui: Animal yra objektas, kuris turi funkcijas Animal.eat(), Animal.sleep() ir pan.

Dėkui už paaiškinimą

Klausimas dar dėl saugumo: kiek supratau naudojant objektus duomenys tam tikru atveju tampa saugesni, nes tiesiogiai duomenys (kintamieji) nepasiekiami, reikia kreiptis per objektą. Kažkaip vien pliusai kol kas matosi, o kokie minusai OOP?

Klausimas dar dėl saugumo: kiek supratau naudojant objektus duomenys tam tikru atveju tampa saugesni, nes tiesiogiai duomenys (kintamieji) nepasiekiami, reikia kreiptis per objektą. Kažkaip vien pliusai kol kas matosi, o kokie minusai OOP?

Klasės leidžia nurodyti, kurie jose esantys kintamieji ir kurios funkcijos gali būti pasiektos iš išorės ir kurie ne. Labai gera praktika yra naudoti "private" daugumai funkcijų ir kintamųjų ir "public" nustatyti tik tuos, į kuriuos kreipiesi iš išorės (Objektas.funkcija() ar Objektas.kintamasis). Einant toliau, sakoma, kad geras objektinis programavimas neturėtų leisti tiesiogiai prieiti nei prie vieno kintamojo (visi jie turėtų būti "private"), o juos pasiekti turėtų būti naudojamos funkcijos: Objektas.gautiKintamąjį(), Objektas.nustatytiKinstamąjį(reikšmė).

OOP minusų nežinau. Mano nuomone, kiekvienas failas turėtų reikšti atskirą klasę ir joje esančias funkcijas / kintamuosius.

Praktiškai visada. Tiek dideliam, tiek ir mažam projekte.

Pagrinde dėl kodo tvarikingumo ir optimizavimo. Nes tą patį objekta gali naudoti keliose dalyse.

Jei pats dirbi su klientais, turėtum žinot ką reiškia kolizija kai

klientai pastoviai siunčia daug pakeitimų ir papildymų.

Ojektinis programavimas nuo to 100% niekada neišgelbės bet padės

tvarkingiau ir paprasčiau dayt pakeitimus.

Sakykim, nori integruoti kelis mokėjimo metodus ir žinai, kad abu jie atlieka funkcijas vienodais pavadinimais, bet pačių funkcijų veikimas skiriasi (priklausomai nuo mokėjimo sistemos).

 

Tuomet: vienas objektas yra PayPal, kitas objektas yra MoneyBookers.

 

Jei nori sugeneruoti PayPal apmokėjimo formą, gali kreiptis PayPal::createForm() (ar PayPal.createForm() - jei ne statinis metodas), jei MoneyBookers - MoneyBookers::createForm().

... ir šiuo atveju, kad viskas būtų dar gražiau, panaudoji Factory design pattern'ą.