OOP programiranje

Pozdrav!

Evo počeo sam da učim oop pa imam jedno pitanje?

Kakva je razlika izmedju postavljanje vidljivosti varijable public i var jer kad postavim var to je isto kao da je public

npr klasa

zar ovdje ne treba postaviti vidljivost varijable

Koja je razlika izmedju var i public?

I još jedno pitanje? Dali sam dobro uradio ovu klasu za spajanje na bazu?

Hvala na odgovoru!

[quote=“susok”]Pozdrav!

Kakva je razlika izmedju postavljanje vidljivosti varijable public i var jer kad postavim var to je isto kao da je public

Koja je razlika izmedju var i public?[/quote]

public, private i protected su uvedeni u PHP verziji 5, a u verziji 4 je postojao samo “var” što je označavalo public vidljivost. U svrhu backward compatibility PHP 5 (i 6) još uvijek podržavaju “var” kao zamjenu za public

Može proći, ali ja bih to sve nagurao u konstruktor ako će se odmah spajati. Ili možeš odvojiti postavljanje varijabli u konstruktoru i samog spajanja u drugoj funkciji.

Dal onda da koristim uvijek public umjesto var?

I dali je vako bolje spajanje na bazu?

Da, “var” možeš zaboraviti jer je samo ostatak iz php 4

Jok :slight_smile:

Ja bih ili napravio spajanje odmah u konstruktoru:

Ili razdvojio kako treba:

a kad ocu odvojiti spajanje sa serverom i odabir baze valjal vako?

Može proći. Jedino onaj prekida_spajanje() bi bilo bolje da je __destruct() da ide automatski.

Iz čega učiš? Ima nekoliko dobrih knjiga za php oop, npr. PHP Objects, Patterns, and Practice.

Postavke za spajanje idu u zasebni config file. Za errore ne koristi die() već zasebnu Error klasu.

evo mislim da je vako najbolje da ostavim spajanje sa bazom

dali mi neko može pokazati svoj primjer klase za mysql bazu?

I kako misliš da napravim posebno mysql_error():

Kad sam radio u proceduralnom programiranje mysql greške sam upisivo u baz vako

I sad taj kod koji uopće nije loš prebaci u klasu i to ti je to.

trebao bi sljedeti ćim više OOP načela.
Svaka klasa je svijet za sebe ali u službi trećeg koda. Klasa koja postoji sama za sebe ne treba biti klasa (u ovom slučaju kao što ti je netko spomenuo trebala bi ti i error reporting klasa).
Prekršio si načelo enkapuslacije (čudim se kako to nitko nije primjetio) jer tvoja klasa je “otvorena” i njezino stanje se može mjenjati.
Prvo bi sve propertije pretvorio u privatne i držao bih se načela enkapuslacije.

Vrijednosti postavljene u konstruktoru su OK, ali opet samo za ovaj tvoj konkretni primjer jer klasa je bez toga beskorisna, negdje drugdje će biti slučaj da će se baš izbjegavati postavljenje u konstruktoru.
Tako da postoji puno načina kako izvesti spajanje na bazu a to ne ovisi o konkretnoj implementaciji već o tome kako misliš svoj kod koristiti i kakva i kolika će biti interakcija (public interface, opet enkapsulacija!!) tvojeg koda sa trećim kodom.

E sad pazi tu riječ enkapsulacija, lakše ćeš naučiti definiciju nego broj svojeg mobitela ali primjenjivati ju, uklopiti je u druga načela, i izvući maksimim od nje, je put kroji traje godina (odnosno tokom čitavog programerskog staža). A sad si zamsili gdje su tek neka druga kompliciranija načela čije definicije se isto protežu u par složenih rečenica (onda mi lik veli da je OOP pisanje klase, što bi čovjek rekao drugo nego da je u pravu:).

A radi se samo o jednoj složenoj rečenici:)

E sad da se ne ediram jer nije edit.
Netko je spomenuo error reporting klasu za db.
Da bi je mogao kvalitetno uklopiti trebaš se pridržavati sljedećg načela koje se zove loose coupilng. Primjenjivanje tog načela je jedno x10 puta kompliciranije neko pridržavanje enkapsulacije.
A to načelo će te naučiti kako da tvoja error reporting klasa ne ovisi o konkretnoj klasi u kojoj je došlo do errora, odnosno u ovom slučaju radi se spajanju na bazu.
Znaći spajanje na bazu i error reporting trebaju biti dvije zasebne stvari koje mogu funkcionirati neovisino jedna od drugoj.
E nadam se da sam ti sad malo bolje približio OOP.

E sad ako si uspješno savladao prijašnja dva načela onda dolazi i treće a to je polimorfizam i dosta ga je teško shvatiti u PHP, a ono ti omogučava, između ostalog, naprednije primjene drugo načela (mislio sam napisati da je drugo načelo bez toga nemoguče izvesti ali nisam jer to nije sasvim točno).

E sad tu postoje još tih načela ovisno do koje razine se želi ići i koju “školu” se želi slušati no ona su u većini slučajeva jednostavna za naučiti a za primjeniti, vrlo mali broj programera ima mogučnost praktično isprobati ta načela.

Pošto je ime teme “OOP programiranje” pa onda da raspalim dok ima sadržaja:)
Danas najkvalitetniji OOP sustav na koji sam naletio u PHP je Magento.
I bilo tko, ako misli da je naučio sve što se može u PHP OOP, neka utipka magento commerce i želim mu ugodne tjedne proučavanja.
Vjerovali ili ne stom stvarćicom se može u većini slučajeva raditi bilo što a da se ne dira sam core. A to je vrijedno skidanja kape:)

Ono što je iznad OOP programiranja je arihiktetura. I podređenosti OOP koda arihikteturi. Nisam to previše proučava ali baš na samom Magentu sam primjetio neka načela dizajna (ne u smislu grafike) arihikteture u rješavanju određenih problema (config files, extension, service soap, template, admin).
I tu je Magento sam vrh. Radio sam u Joomli i primjetio isti dizajn arhikteture (to sam već pisao u jednoj temi) ali na puno primitivnijem nivou sa puno manim mogučnosti.

E sad da nebi bio neshvaćen, dizajn arihikteture aplikacije u mojem slučaju (jer mislim da se wiki ne slaže s menom) bi recimo bio nadogradiv template engine u kojoj mjenjate ponašanje core template file tako što kreirate nove foldere, u njih stavljate svoje file i dobivate novo ponašanje vaših template file-ova.

Jedini način da te dvije klase budu potpuno zasebne je kroz trigger_error() i set_error_handler() funkcije, mada ta solucija nije idealna.

I to je jedan od rijeđih primjera gdje stvari koliko-toliko funkcioniraju u PHPu…

Po čemu je to drugačije od najobičnijeg MVC frameworka gdje se klase proširuju ili zamjenjuju?

[quote=“voajer”]Jedini način da te dvije klase budu potpuno zasebne je kroz trigger_error() i set_error_handler() funkcije, mada ta solucija nije idealna.

I to je jedan od rijeđih primjera gdje stvari koliko-toliko funkcioniraju u PHPu…
[/quote]

Ne radi se o potpunom odvojanju već o primjeni “loose coupoling”, odnosno klasa ne mora znati ništa o drugoj klasi već samo njezin interface.
Moguča rješenja kroz interface, extends, abstract, polifmofizam (sva tri načela).

[quote=“voajer”]
Po čemu je to drugačije od najobičnijeg MVC frameworka gdje se klase proširuju ili zamjenjuju?[/quote]
MVC framework je abstraktno rješenje dok je Magento konkretno rješenje.
MVC framework riješava konkretne probleme na jako primitivnoj razini (razini primjene).

Odnosno MVC framework ti omogučava da izgradiš svoj template engine (konkretno rješenje) dok Magento kao konkretno rješenje omogučava izmjenu tog konkretnog rješenja bez uplitanja ne u Zend framework već u Magento core.

[quote=“gorrc”]Ne radi se o potpunom odvojanju već o primjeni “loose coupoling”, odnosno klasa ne mora znati ništa o drugoj klasi već samo njezin interface.
Moguča rješenja kroz interface, extends, abstract, polifmofizam (sva tri načela).
[/quote]

Avaj, zar nije potpuna odvojenost bolja od “loose coupling”?

Naravno, govorimo o principima, ne implementaciji.

[quote=""]
Odnosno MVC framework ti omogučava da izgradiš svoj template engine (konkretno rješenje) dok Magento kao konkretno rješenje omogučava izmjenu tog konkretnog rješenja bez uplitanja ne u Zend framework već u Magento core.[/quote]

Da, no onda je Magento lijep primjer konkretnog riješenja a ne nešto sasvim novo.

[quote=“voajer”]Avaj, zar nije potpuna odvojenost bolja od “loose coupling”?

Naravno, govorimo o principima, ne implementaciji.
[/quote]
Ali nije ni bit da klase bude zasebne, već da bude zamjenjive, i da traže nešto što nije vezano za samo stanje klase (i tu opet dolazimo do načela enkapuslacije a pričamo o loose coupoling).
Nepridržavanje jednog načela ugrožavamo drugo načelo!!??


Da bi postajalo uspješno pridržavanje jednog načela zahtjeva se i uspješno pridržavanje drugih načela.

[quote=“voajer”]
Po čemu je to drugačije od najobičnijeg MVC frameworka gdje se klase proširuju ili zamjenjuju?[/quote]
Stvarno si me naveo na razmišljanje. :cuga2:
Zato jer na Magento gledam kao FINAL (iako nisam imao potrebe raditi sa time).

dali mi neko može prikazati primjer svoje database klase i klasu upis mysql greški u bazu?

Ja sam pokušavao nešto vako da napravim al izgleda da nevalja

Hvala!

[quote=“gorrc”]Ali nije ni bit da klase bude zasebne, već da bude zamjenjive, i da traže nešto što nije vezano za samo stanje klase (i tu opet dolazimo do načela enkapuslacije a pričamo o loose coupoling).
[/quote]

Da, no valjda postoje dva ekstrema u tom slučaju - potpuna odvojenost i tight-coupling. Pritom je solucija bolja što je coupling manji i tako do razine potpune odvojenosti - dakle, gdje klasa koja poziva funkciju niti ne zna kojoj klasi ta funkcija pripada, samo zna da određena funkcija vraća određeni rezultat kada joj se pruže određeni argumenti i da određena placeholder klasa sadrži određene property-je.

@susok

Ako želiš vidjeti primjer kvalitetnog koda, pogledaj u nekakav framework. Ili, kao što je gorrc predložio, u Magento.

Što ti sada to znači?

[quote=“voajer”]Da, no valjda postoje dva ekstrema u tom slučaju - potpuna odvojenost i tight-coupling. Pritom je solucija bolja što je coupling manji i tako do razine potpune odvojenosti - dakle, gdje klasa koja poziva funkciju niti ne zna kojoj klasi ta funkcija pripada, samo zna da određena funkcija vraća određeni rezultat kada joj se pruže određeni argumenti i da određena placeholder klasa sadrži određene property-je.
[/quote]
To i jest loose coupiling a potpuna odvojenost ne može postojati jer uvijek jedan objekt radi sa drugim i ako ništa drugo mora postojati inteface od objekta.

A stvarno neznam:)
Magento je gotov proizvod s kojim se radi dok Zend framework je ipak nešto na ćemu se gradi proizvod.
Nešto u smjeru.

Recimo Zend forme su temelj na kojima možeš graditi dok Magento forme su usmjerene prema Magentu i njegovim potrebama.
Recimo da postoji manje abstrakcije jer su neke stvari definirane time što Magento web shop. No recimo to se u Magentu rijetko gdje primjeti, zato je i tako dobar.