Citat:
|
Originalno napisao ivanhoe
Osnovni problem kod pokusaja da se proces generalizuje (sto je naravno dobra stvar) po mom iskustvu je sto u nekom trenutku funkcija/klasa koju pises pocne da bude preterano komplikovana da bi podrzala svih 200 miliona specificnosti koji mogu da se dese... Ili drugi pristup je da pravis specificnu metodu za svaki taj slucaj, a onda zavrsis sa toliko metoda (obicno slicnih imena) da vise covek ne moze da se seti kad sta koristiti, a one sede u kodu, trose meoriju i skupljaju prasinu...
|
Sta je bolje, imati 200 specificnosti isprogramiranih koje kude po kodu aplikacije (a verovatno i ponavljanih) ili imati te iste specificnosti isprogramirane kroz jednu klasu (ili grupu wraper funkcija). Posao programiranja je manje vise isti, u jednom slucaju programiras na licu mesta, gde se zadesi potreba, a u drugom to isto programiras, ali na uredjen nacin, koji ti omogucuje da na neki nacin stvar organizujes, uvidis mogucnosti uopstavanja i najcesce da isti kod upotrebis na vise mesta. Nema tu viska koda koji gura prasinu. To je isti kod, samo drugacije organizovan i iskoriscen manje ili vise efikasno.
Citat:
|
Originalno napisao ivanhoe
Mislim da je glavna fora efektivnog programiranja da se oceni kad treba stati sa "uopstavanjem" i neke stvari ostaviti namerno nepokrivenim, jer su retke, a dovele bi do "viska" koda... Najprostiji primer ov logike je ona insert metoda sto sam naveo u proslom postu, ona je super za obicne inserte, das joj niz podataka i ime tabele i ona ih ubaci. E sad sta ako treba umesto konkretne vrednosti ubaciti mysql funkciju (recimo NOW() ), sto cak i nije toliko redak slucaj? To namerno nije podrzano, mada verovatno ne bi bilo komplikovano smisliti dodatni parametar ili regExpom proveriti da li je parametar funkcija. Ali to bi iskomplikovalo postojeci kod i usporilo rad metode koja se cesto koristi, a zarad pokrivanja slucaja koji se redje koristi, a po meni je to losa ideja...
|
Fleksibilnost i kompromisi su uvek bili tajna uspeha. Meni se cini da treba iskoristiti prednosti svakog pristupa i apstrakciju uraditi na bar dva nivoa.
Prvi je onaj koji si ti prikazao u primeru: klasa koja obavlja sve one standardizovane procedure nad tabelema i podacima. Bilo bi idealno kada bi toj klasi mogao da "nacrtam" model baze a da mi ona obezbedi sve potrebne mehanizme pocev od kreiranja same baze pa do standardnih funkcija.
Drugi nivo su klase koje nasledjuju osnovnu klasu u prosiruju je specificnostima potrebnim za konkretnu namenu. One bi po pravilu sadrzavale rucno pisan kod.
Tako imas mogucnost da radis onako kako ti u trenutku odgovara, mozes da uopstavas, ako mislis da je potrebno, a i ne moras jer imas prostora da za specifican problem napises i specifican kod.
Ono sto ces sigurno dobiti to je citkiji kod, koji je lako pratiti i odrzavati.
Citat:
|
Originalno napisao Ilija Studen
Sad ćete mi još reći da je mana što recimo PDO ili ADOdb imaju poršku za toliki broj platformi?
|
Taman posla, dobro je to i lepo, ali biblioteke prosto ne mogu da pokriju sve i uvek postoji potreba da se napis eneki custom kod. Tog momenta portabilnost pada u vodu, jer ja uopste necu da se smaram sa tim da pisem kod koji ce da radi na 16 baza, od kojih samo dve-tri poznajem dovoljno da bih eventualno mogao da razmisljam o podrsci za njih.
Citat:
|
Originalno napisao Ilija Studen
Uostalom, zašto koristite PHP? Možete sesti, smisliti rupu u saksiji i svoju novu maestralnu web aplikaciju napisati u C-u
|
Joj, nemoj mi stajati na zulj. Upravo tako nesto radim, pravim novi jezik koji ima istu funkciju kao i PHP. Razlika je samo sto je drugi jezik. U stvari i ne zalim se, prilicno je interesantno, kao da sam prosao kroz ogledalo pa sad ceo problem vidim "s one strane".