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.
Glupost? Prilicno teska rec od nekoga ko nije postavio nijedan primer koda. Ako si vec samoproklamovani guru (mozda i jesi, ne znam), zasto ne postavis neke primere koda kako bih razumeo? Najlakse je obrisati gomilu mojih postova jer se ne slazes za mnom; daj da vidimo i konkretan razlog.
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.
Sto se tice tih napamet ideja, ti si jedan od onih koji samo ostavljaju linkove ka nekim tutorialima i definicijama. Ja sa druge strane kroz primer objasnjavam kako radim, a da si pogledao bolje, video bi da se isti kod bas i ne ponavlja toliko.
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?
Nezavisno? Ne razumem te; zasto ne bih imao zajednicke metode u basemodel klasi ako tu istu metodu dele svi objekti? Konkretno iz posta koji si obrisao je metoda getTitle(). Jel treba da je ponavljam 32 puta zato sto imam 32 klase?
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.
Ne vidim nista lose u tome da klasa (npr. Category) ima svoje logicke funkcije dok se BaseCategory stara o reprezentaciji u bazi. Reci mi sta fali ovom pristupu?
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.
Naveo sam primere; ti ne znas koliko je taj sistem spregnut ili nije.
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.
I to sam postovao, ali si verovatno i to obrisao. 'Jednostavan model podataka' tesko da je mogucnost da svaki objekat moze, ali ne mora, biti visejezican i da jedna metoda getTitle() se sama brine o tome. Naravno, deep validacija prevoda se podrazumeva. Kako sam to resio? U mom 'nategnutom' sistemu objekat koji je visejezican ima metodu 'getTranslationRelation()'. Ok, cudan naziv, ali to je sve. Od tada pa nadalje, objekat je visejezican. Pored nove many2many klase tipa CategoryTranslation, apsolutno nijedna metoda vise nije potrebna.
U pravu si, vrlo nategnuto i tesko vezuje ruke nekom ko bi nastavio moj rad

ps.
kad si vec uhvatio zalet sa brisanjem mojih poruka, ostavi ovu bar do ujutru. Nema smisla ubiti je pre nego sto sunca vidi u zivotu

Druga stvar:
zato sto ti radis na drugaciji nacin, ne znaci da ja mozda nisam u pravu
