Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

Kako će sada videoFile.IsRateable() da vrati false kada on nema pojma za ovaj audio fajl koji je smešten unutar iste kategorije?


Šta radiš u slučaju kada trebaš da izmeniš perzistentni sloj? Imaš zahtev da ne koristiš Doctrine ORM, već neki drugi ORM ili da u potpunosti izbaciš ORM, a svi entiteti ti nasleđuju upravo Doctrine_Record? Entitet može da se učita iz baze, ali takođe može i pozivom nekom web servisu, iz xml fajla, itd.


Želim da kažem da ovo može da prođe samo u nekim jednostavnim slučajevima kada je potrebno izvalidarati da li je uneseno ime i prezime, itd.
U slučajevima kada validnost nekog entiteta zavisi i od drugih entiteta u sistemu, tada ili validaciju moraš da izmestiš na drugo mesto ili sve te druge entitete moraš da zbudžiš u jedan da bi ono IsValid bez parametara moglo da radi.


E pa to je ono što me i zanima. Ako child objekat sme da se sačuva samo preko svog parent-a, zašto child ima public Save metod?
Ovo govorim sa strane korisnika tvog API-ja.

_{[Ovu poruku je menjao Dejan Carić dana 11.05.2010. u 00:02 GMT+1]}

---

'Rusi' se 90% njegovog koda . Umesto tog silnog nasledjivanja mogao je da razdvoji apstrakciju od implementacije ORM-a
i kroz abstract factory da 'bira' engine koji ce aplikacija koristiti .
Kad se pojavi novi brzi i bolji :) implementira ga nezavisno, a ostatak aplikacije se ne bi menjao ,
tj, potpuno bi bio transparentan za za bilo koji ORM ili engine ..
http://en.wikipedia.org/wiki/Bridge_pattern


To i jeste fora , sto posmatra oop usko ,
samo kroz funkcionalnost jedne klase pa otud i metode bez parametara koje rade sve .

---

Znate šta je problem - vi gledate OOP na način da tražite mjesto da ga negdje uglavite, samo zato jer se radi o "trendu", a ne o konkretnoj potrebi za koju vidite rješenje jednom od objektnih tehnika / design pattern-a. Netko je rekao da se sve može postići samo funkcijama - i to je tačno, ali na isti način kao što je sve moguće postići asemblerskim kodom (može i niže, ko želi).

Pustite sada nasljeđivanje, polimorfizam i ostale sitnice. Glavni razlog OOP-a je povećanje abstrakcije, i lakše sagledavanje na stvari - to je ono što treba biti motiv za sve. Pomenute tehnike su tu da ostvare taj motiv, ništa više. Abstrakcija koja se postiže micanjem na veći stepen razvoja (na objektni pristup sa funkcijskog) je neprocjeniva tehnika koja je omogućila software ovakvim kakav je danas; i da napomenem da pod tom vrstom software-a ne mislim na kernel-e sistema ili neke mission-critical procese sa veoma ograničenim resursima gdje je sve osim asemblera/C-a "preteško". Programi od nivoa naprednih dokument editora (kao MS Word) pa do ERP sistema bi bili nemogući za izvesti bez OOP-a.

Problem većine PHP programera sa shvatanjem OOP-a i racionalizaciom njegove primjene je u nedovoljnoj kompleksnosti njihovih projekata. Ruku na srce, većina ne piše iole komplikovanije enterprise sisteme, kamoli šta drugo. Lako je koristiti funkcijsko programiranje na bazi sa 5-10 tabela.

Šta OOP omogućuje?

OOP omogućuje da za početak particionišete (princip enkapsulacije) dijelove sistema tako da umjesto da vodite računa o 48 stvari odjednom, vi smanjite taj broj na recimo 5-6. Uzmite za primjer evo komunikaciju sa bazom podataka koju stalno spominjete. Bez OOP-a, vaš kod se svodi za CRUD (Create, Read, Update, Delete) funkcije od kojih svaka odrađuje neki dio posla. Uzmite za slučaj da imate bazu sa 40 tabela. To je ~160 funkcija. Uzmite da morate imati transakcijska ograničenja na određene radnje koje uključuju određene skupove tih funkcija (recimo, prebacivanja novca u banci s jednog računa na drugi uključuje upis u tabelu transakcija, te dva update-a u tabeli stanja racuna - sa jednog + na drugi -). Ovo bi morali odraditi tako da napravite novu funkciju koja obuhvata te 3 u transakcijski okvir sa BEGIN - COMMIT - ROLLBACK. To dodaje još 30-ak funkcija. Uzmite onda da odjednom morate voditi audit logove svih korisničkih radnji, svih transakcija. Gdje ćete to uraditi? Mjenjati tih svih 30 funkcija?
Nemojte samo sada reći, pa dobro - to se može prebaciti na stored procedure u bazu. Pozivanje tih stored procedura sa parametrima nije ništa drugo nego micanje problema na drugo mjesto plus uvođenje dodatne kompleksnosti razdvajanjem koda na dodatna dva sloja (iako, to je normalna praksa ako je potreba za time realna - kao u bankama gdje je sigurnost podatka na prvom mjestu).

Particionisanje se radi pomoću par tehnika. Nema smisla objašnjavati šta znači referencirati jedan objekt iz drugog (asocijacije itd...). Najvažnija tehnika je definisanje granica vidljivošću podataka i funkcija. Private / public / protected oznake postoje ne radi otežavanja stvari, nego olakšavanja programiranja uvođenjem konceptualih granica u kod. Lako je vama sa 10 funkcija znati koju treba kada pozivati. Uzmite da bilo koji teži scenario zahtjeva da se slijedi tačno definisan postupak za neku radnju. Uzmite da neki objekt HTMLPage ima funkcije (mrzim ovo zvati "funkcije" kad je u OO svijetu pravilno reći metode, ali eto...) CreateHeader(), CreateBody(), CreateFooter(), bez parametara, koje sve same znaju odraditi. Da bi sve ispravno radilo, potrebno je pozvati ih u tome redoslijedu. Ko kaže da se neće naći neki rookie programer koji će ih pozvati nepravilno - i unijeti bug u program? Ko kaže da kada bude postojalo 2000 funkcija kroz 40 file-ova da nikada neće biti situacija da se nešto pozove nepravilno? Ograničenja koja sami postavljamo u OOP-u pomažu da se takve vrste grešaka svedu na minimum. Stavite ove tri funkcije na private vidljivost, tako da ih kod van klase ne može pozivati. Napravite public funkciju koja poziva ove tri u pravilnom redoslijedu. Public funkcija je vidljiva vanjskom svijetu, private nisu - te zato nitko ih ne može niti direktno zloupotrijebiti.

Upotrebom particionisanja stvarate black-box kocke koda za čije korištenje ne morate znati apsolutno ništa o njima. Za shvatanje toga primjenom OOP-a, ne morate koristiti sve OOP tehnike (ne treba vam niti nasljeđivanje, niti polimorfizam). Jedan od najosnovnijih design pattern-a je layering, tj. podjela koda u slojeve. Ako svaki sloj predstavimo objektima, i u svakome pozivamo samo objekte sloja ispod - dobiva se ogromna organizacija koda, a o manjoj mogućnosti grešaka i preglednijeg koda da se ne priča. UI sloj može pozivati poslovnu logiku, ona može pozivati sloj za komunikaciju sa bazom podataka, itd... Čak i ako sve ostavite u funkcijama, kad ih barem stavite u zajednički objekt, osiguravate da onaj koji ih poziva zna šta radi, jer mora instancirati taj "layer".

Netko je naveo da se kod može organizirati i jednostavno kroz file-ove i include naredbe. Istina, samo što taj pristup nema niti jednu od ostalih OOP osobina osim smanjenja veličine koda (i to samo djelomičnog smanjenja). Time ne dobivate nikakvu abstrakciju, ne možete postaviti nikakva ograničenja, te nema polimorfizma i nasljeđivanja, što je najjača OOP osobina.

Govoreći o polimorfizmu i nasljeđivanju, da nastavim s njima na primjeru rada sa bazom podataka. Pravilnom upotrebom osnovnog modela nasljeđivanja možete napraviti po objekt za svaki entitet koji imate u bazi. Prvo na što ćete naići je osobina da svaki taj entitet (tabela) ima ID. Zašto to onda ne prebaciti u zajedničku nad klasu? Jedini varijabilni parametar nad-klase može biti ime tabele entiteta. Funkcija za dobavljanje sljedećeg ID-a iz baze je ovisna u većini scenarija samo o imenu tabele u kojoj se traži ID, što je kvalificira da ide u nad-klasu. U složenijem scenariju, kada to nije dovoljno, ili kad se koristi neka složenija tehnika, napravite objekt IdGenerator, koji ima funkciju Generate(). Nasljeđivanjem napravite objekte kojima je IdGenerator nad klasa, i od kojih svaka implementira funkciju Generate() prema svome određenom scenariju. Jedna može dobavljati ID preko MAX() SQL funkcije. Jedna može koristiti posebnu tabelu samo za ID-eve. Jedna može iskoristiti SQL Server ili Oracle pogodnosti. Mogućnosti su neograničene. Ona naša prva nad-klasa za sve entitete, koja sadrži funkciju za generisanjeg sljedećeg ID-a, može jednostavno delegirati taj posao na konkretnu instancu IdGenerator klase, što nije ništa drugo nego najjednostavnija primjena polimorfizma.

Drugi primjer je nešto što nedostaje PHP-u, a to je objektna hijerarhija za mnoge očite stvari. Recimo, u PHP-u ja ne mogu da se oslonim da postoji neka funkcija koja će se automatski pozvati kada je potreban string tip podataka. Jezici kao C# ili Java imaju realizacije ToString() funkcije koja je implementirana u baznoj Object klasi, koju svaka klasa implicitno nasljeđuje (znači, nasljeđivanje + polimorfizam). PHP nema DateTime objekte, pa da mogu raditi sa vremenskim zonama, ili da ih mogu oduzimati da dobijem TimeSpan objekt koji sadrži podatke oduzimanja dva datuma. Primjera je hrpa.

Čak i bez sofisticiranih alata, za ne-presložene projekte, moguće je da sami napravite osnovni framework za manipulaciju tabelama u bazi podataka, koji se zasniva na jednostavnom nasljeđivanju entitet klase, i dopunjavanju imena tabele, i polja u bazi podataka. ORM-i rade to isto, samo sa još jednim slojem između, i gomilom ostalih mogućnosti kao što su Identity Maps, Lazy Loading, Query objekti, itd...

Pošto ovaj post nije pokušaj objašnjavanja nekome tačno gdje i kako može primjeniti OOP - uzmite fino knjigu "Design Patterns: Elements of Reusable Object-Oriented Software" i pročitajte je od korica do korica sa vježbanjem i pokušavanjem dubokog razumijevanja svakog primjera. Ja nisam upotrebljavao OOP ni 20% dok nisam počeo čitati ovu knjigu. Sada ne shvatam kako to nisam prije znao - jednostavno dobijete taj osjećaj povezanoti sa OOP pristupom da ništa drugo nema smisla.



Što se tiče konkretnih postova u ovoj temi, gledanje OOP-a kao broj parametara u metodama je loše. Nitko vas ne ograničava da imate metodu sa 5 parametara, niti metodu bez i jednog. Cilj je praviti kod koji se ravna prema SOLID principima, a to je već nešto što zahtjeva mnogo i mnogo rada, truda i volje za pravilnim OOP-om. Iz ovih principa dobivaju se svi design pattern-i od kojih eto za vas web programere, MVC je neprocjenjiv.

Principi koji se isto stalno spominju, i prožimaju s ostalima, su tight i loose coupling. Poenta je imati što manji broj dependency-a među objektima, tako da izmjena na jednome ne pravi ripple-effect na ostalima. Broj parametara naravno pomaže u tome, ali ne može se jednostavno reći sad ću praviti funkcije bez parametara, i to je to.

BTW, OOP nije niti blizu kraja, nakon njega imate TDD, pa dalje da se ne priča ... A sve je u svrhu povećanja abstraktnosti, osiguravanja od bug-ova, i što kvalitetnijeg razvoja software-a...

---

E pa to se desava kad koristis bilo koji ORM. Jednostavno, stvari tako funkcionisu i ja to nikako ne bih izbacio. Evo ti primer:
Song uvek pripada nekom Album-u. Ali, ja mogu da napravim posebno izmenu Song-a, ali mogu i jednu jedinstvenu formu gde ce se u isto vreme editovati Album sa svim pripadajucim Song-ovima. To sto ti pitas mi nikako nije jasno; ako ne zelis da Song koristi direktno save() metodu, nemoj da kreiras formu za njeno editovanje. Jednostavno.

Mala forma za editovanje pesme ce koristiti $song->isValid(). Velika forma za izmenu Album-a, zajedno za pripadajucim pesmama, koristice $album->isValid(). Ako samo jedna pesma ne prodje validaciju, isValid() vraca false. Ako pokusas ipak da snimis, dobices exception. Vrlo, vrlo jednostavno, ne vidim nikakav problem.


_{[Ovu poruku je menjao Goran Rakić dana 16.06.2010. u 02:01 GMT+1]}

Offtopic na OOP principe: kome je još stalo da ORM framework abstraktuje pomoću Abstract Factory-a? Baze može mijenjati slobodno kroz ORM (ne znam za Doctrine, ali pretpostavljam). Ako sad treba zamjeniti i čitav ORM, to je onda daleko jednog prosječnog, čak i veoma nad-prosječnog PHP projekta. Jbg, ne pravi svaki drugi PHP programer Facebook aplikacije ...

Nekada svu priču traženja savršenstva treba svesti i na ono najmanje što zadovoljava. Keep It Simple and Stupid - KISS.

---

@Mitke
Po meni ako metoda moze da se svede na ovakvu funkciju onda mi to bas i nije neka prava primena OOP;
function isReateable()
{
global var1, var2; //umesto $this->var1; $this->var2;
}


A sto se tice brzine pisanja koda obicno ti FW imaju gomilu gotovih funkcija pa je zato brze kodiranje.
Dobro napisani skupovi funcija takodje mogu da mnogo ubrzaju izradu stranice i ne bih poredio.

Hocu da kazem da bi sve to kroz php moglo da prodje kao proceduralno programirane (mozda nekada losije mozda nekada bolje, ali moze) za razliku od nekih drugih programskih jezika kao sto je recimo C#.net gde nista ne bi moglo da prodje kao proceduralno!

---

Pa evo ti primer:
Ja imam jako poverljivu bazu podataka sa korisnicima i nekim proizvodima.
Hoću da angažujem tebe da mi napraviš online web shop, ali ne mogu da ti omogućim pristup bazi jer su tu njihovi matični brojevi, stanja na računima, itd.
Umesto toga, ja sam napravio web servis i napravio metode koje ti omogućuju da dobiješ samo one stvari koje su ti potrebne.
Kako ćeš ti preko tog tvog framework-a da instanciraš nove entitete preko komunikacije sa mojim web servisom? Nikako.
A mene baš briga koje ćeš ti rešenje da koristiš dokle god je to brzo i pouzdano.



Sutra IBM izbaci novu verziju baze, ja puknem $10.000 na licencu i hoću da se web shop vrti na njoj. Upite koje ćeš da izvršavaš nad njom su u 99% slučajeva isti kao i za MySQL, ali gle malera, Doctrine npr. ne podržava tu verziju baze, dok neki drugi ORM podržava.

Hoćeš li:
1. Čekati 3 meseca da Doctrine izbaci podršku za novu bazu
2. Promeniti ORM
3. Odbaciti visokobudžetni projekat

---

Ti ozbiljno koristis global? Bez ljutnje, ali koriscenje global-a je veooooooooma los pristup programiranju (da ne kazem neku ruzniju rec). Pa zamisli da ja treba da nastavim dalje tvoj kod a $var1 konstantno dobija neku cudnu vrednost jer sigurno necu gledati svaku funkciju koje se poziva pre i posle moje. Zamisli da i moja funkcija ubaci nesto u global, a zatim se pozove neka koja totalno poludi. Tvojom logikom, ja bih morao da proverim SVAKU funkciju pre nego sto sednem da radim. Mojom logikom, proveravas samo tu metodu.

_{[Ovu poruku je menjao Goran Rakić dana 16.06.2010. u 02:05 GMT+1]}

Promenicu ORM. Znaci, necu koristiti fromArray($_POST) vec cu koristiti useArray($_POST) ili koja vec. Ili jos bolje; ja od doctrine-a ionako koristim nekih 6-7 metoda:
fromArray, synchronizeWithArray, isValid, save i mozda jos koja. Ostale metode nisu vezane za ORM, tj. metoda isRateable() nema veze sa Doctrine-om. Znaci, u baseModel klasi bih napisao nesto poput:


tako da bi prelazak na novi ORM bio prilicno brz i jednostavan proces. Sto se tice baznih definicija npr. $this->hasColumn() gde se opisuje kolona u tabeli i njena validacija, to bi svakako moralo da se promeni jer to DIREKTNO zavisi od ORM-a i njegovog API-a. Moja gruba procena je da bi sa doctrine-a na npr. propel, za projekat koji ima visejezicku podrsku i 15 razlicitih objekata (bez many2many za prevode) trebalo u vrh glave 20 dana. Ako poznajem taj ORM i radio sam u njemu, ne bi trebalo vise od 3-4 dana, ORM programi su jako zaista jednostavni za koriscenje.



Zasto si tako uveren u to? Ja dovlacim instance objekata koriscenjem Doctrine_Query klase. Umesto nje, koristio bih mogu klasu ciji je API identican Doctrine_Query klasi, ali bi podatke uzimao preko metoda koje si mi ti omogucio.
Drugo: posaljes mi sql dump gde bi 10 linija koda izmenila poverljive podatke. Jos jednostavnije i brze. Za program koji trenutno radim sam i dobio SQL dump za izmenjenim licnim podacima. Nema username-a, nema email-a, pa opet radim.

@mitke

Ne koristim global i znam za posledice samo sam hteo da kazem da OOP nije samo citljiviji kod vec nesto sasvim drugo i u php-u sustina promice, OOP se koristi za citljiviji kod i nasledjivanje koje opet moze i funkcijama da se resi. Nema nesto slucajva kada je MORAM da koristim OOP;
I kod klase moras da setujes $this->var1 i $this->var2 pa bi trebao da znas kada i kako se setuju a istovremeno moras da otvoris 10 fajlova da bi to pronasao.
Opet kazem da sam za OOP zbog nekih drugih stvari ali ne zbog pravljenja objekata i nasledjivanja, najvise zbog gomilu gotovih stvari na kojima je radjeno godinama, brznu savladavanja tih stvari i pronalazenju zajednicke logike medju programerima jer te OOP navodi sa slicno razmisljamo.

---

Ako neko kad pomisli da OOP misli na nasledjivanje ?! Onda po mom skromnom misljenju vi kreirate tako "nekvalitetan kod" da je to neverovatno. Ne kazem ja da je naslednjivanje zabranjeno, ali kljuc je interfejs ! Ako neko ovde uopste govori u OOP a u svom kodu se ne oslanja u ogromnoj meri na interfejse taj slobodno moze da se batali OOP

---

Mitke013, zamolio bih te za malo manje samo-promocije ovde. Ok je davati primere koda ali u dobro broju slucajeva je ocigledno da je promocija necega drugog u pitanju. Recimo video za "paginaciju u jednom redu" si zakacio bar 3 puta na ovoj temi, i na jos par tema (btw, paginacija u jednoj liniji koda nije nista previse inovativno i ne vidjeno do sada). Zadrzi diskusiju na idejama boljeg programiranja, bez prozivki, tj ne na tome kako je tvoj kod bolji od drugih kako ne bi dolazilo do offtopic prepucavanja ciji je manji (ili veci) kOd i ko koliko zaradjuje zbog toga.
Dobar deo ovde opisanih stvari nije niciji licno izmisljeni stil, tako da nema potrebe ulaziti u licnu prozivku.

Usput, kompetentnost da li je neko dobar u programiranju ne moze klijent oceniti, jer da on zna kako treba, sam bi ga isprogramirao in the first place. Uspesnost u poslovanju nije merilo kvaliteta koda i obrnuto, a ovde se diskutuje o programiranju, ne o poslovanju

---

Džiiz... Šta ću ja jadan koji kodiram u pure-OOP jeziku koji ne poznaje koncept interfejsa... :) Kako ću ja da batalim OOP?

Potpisujem ovo kako je Saphire objasnio OOP.

---

Što se implementacije toString-a tiče, PHP to i te kako podržava: http://www.php.net/manual/en/l...p#language.oop5.magic.tostring.

Za rad sa datumom/vremenom, PHP ima sasvim solidnu built-in klasu: http://php.net/manual/en/book.datetime.php.

Aj' daj još neki primer, pa da vidimo dal' PHP ima rešenje i za njega, a kladim se da ima.


Goran Rakić: Mala dopuna za bolje razumevanje toka diskusije. U PHP-u je ovoo toString čist hack, uostalom i zove se magična metoda toString. Mali problem je što ne postoji typecasting operator kao što to postoji u nekim drugim jezicima, ali to nije prepreka za OOP koncept. Veći problem je što ne postoji method overloading, mogućnost da se pozove različita metoda za različite tipove argumenta metode. Može da se imitira switch-om i instanceof operatorom.

_{[Ovu poruku je menjao Goran Rakić dana 16.06.2010. u 02:15 GMT+1]}

Mijesate ovde mnoge stvari. Mislim da je ono sto vas interesuje prvi od SOLID principa http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
Single responsibility principle koji kaze objekt tj. klasa treba da ima jednu i samo jednu odgovornost. Odnosno klasa mora imati samo jedan razlog da se mijenja.

Zasto je ovo bitno?
Zbog pisanja unit testova. Kad pisemo unit testove bitno je da klasa ima samo jednu odgovornost i da mozemo da izoliramo tu klasu od ostalih u projektu i da je testiramo nezavisno od drugih klasa.
U slucaju da ne pisete unit testove za svoj kod, da ne koristite patterne i slicno onda mozete i potrpati sve funkcije u jednu klasu onda nije ni bitno...

---

Clanak na wikipedii je uzasno kratak i nista nije rekao. Ajde objasni svojim recima tu ideju.

Koliko mi se cini, ti si za to da se funkcije tipa getCreatedAt() i getUpdatedAt() drze u klasi npr. Objecttimes (ili slicno, nije vazno), isRateable(), isVoted() u klasi Statistics itd...? Ili nisam dobro razumeo

Hm SOLID principi su defacto standard za OOP vec nekoliko godina... Detalje o njima mozete lako pronaci na netu. Jedan od linkova Uncle Bob

E sada neda mi se citati ovaj ogroman post, ali mislim da bi prije bilo getCreatedAt() i getUpdatedAt() u klasi npr. Objecttimes, funkcija isRateable() u klasi Rating
isVoted() u klasi Voting i sl.

Ako vas interesuje najbolji nacin da naucite SOLID principe preporucujem sledecu seriju videa:
http://www.dimecasts.net/Casts/ByTag/SOLID%20Principle

---

@Tema

ja recimo klase pravim da budu realne. mislim da sadrze ono shto objekt treba da ima.
i funkcije i atribute,

a uvek imam i jednu ili par statichnih klasa
uglavnom Misc klasu

koja mi sluzi za sve funkcije koje nisu vezane za objekte
a uvek ima i takvih tipa dodajDane($brojDANA), checkInputFormat($nekaPromenljiva) ...

---

@mitke013, ostali:

Deluje mi da je ovde između ostalog problem da se razume ideja Responsibility-driven design OOP projektovanja i ideja Separation of concerns modularnog programiranja.

Na primer, ona tvoja metoda sa četvrte strane koja koristi $_COOKIE je glupost teška. $_COOKIE podatak tu mora da bude ubrizgan spolja u stanje objekta, a ne da objekat posegne napolje u kontekst. U tom trenutku si ubio svaku enkapsulaciju koja je važan koncept.

Naučio si neke ideje napamet (ono što si napisao o globalnim promenljivama, za šta se slažem) i ne vidiš dalje od njih. U ovom slučaju tvoj $_COOKIE nije ništa drugo nego globalna promenljiva. U diskusiji pišeš kilometarske postove sa jednim te istim kodom jer ti se tako čini kako imaš nove argumente, to je iritirajuće i naporno za čitanje.

Dobra tehnika koja će unaprediti kod koji pišeš je da razmišljaš o nekom korisniku dela aplikacije, jednog objekta. Šta je to što taj objekat radi? Koje podatke deli? Da li je stanje potpuno enkapsulirano u objektu ili se nešto ubrizgava spolja? Da li je objekat dovoljno modularan da nezavisno postoji?

Drugi savet je da malo zaboraviš na ORM, jer ORM != OOP.

ORM ima ružnu naviku da spoji tvoj objekat domena (ono sa čim radiš u aplikaciji) i reprezentaciju tog objekta u bazi podataka, što ja osim u najjednostavnijim slučajevima tumačim kao dve potpuno različite stvari.

Da bi SoC živela u kodu, objekti moraju da budu neuvezani (coupling). Ovim teškim nasleđivanjem i stapanjem slojeva, uz razrušenu enkapsulaciju ti dobijaš izrazito spregnut sistem u kome nemaš šansi bilo šta da čačneš na infrastrukturnom polju.

Brzinu razvoja vidiš samo zahvaljujući primeni Doctrine ORM-a, na račun brzine izvršavanja. Izgleda da imaš sreću da radiš samo sa jednostavnim modelima podataka, čim od njega do sada nisi dobio ospice.

---