OOP vs PP vs ?

[2easy]

jau atkal izklausās pēc spama, bet šie visi lielā mērā tiešām ir gaumes jautājumi...

 

lai kā arī organizētu kodu un lai kā arī to pēc tam nosauktu (mvc vai watever kā), galvenais ir būtība, kāpēc tas tiek darīts: lai atvieglotu/paātrinātu izstrādi/uzturēšanu. vai ne? tātad kādam tā likās ērti. vēl kādam arī. vēl 10 miljoniem citu developeru arī. un viņi taisa augšā web applikācijas ar savu mvc. bet citi 10 miljoni developeru taisa kkā savādāk, kā nu kuram ir ērtāk

 

galvenās lietas, kas tiek nodalītas atsevišķi, ir datu pieprasījumi/query (ko mvc sauc par model) un ui attēlošana/echo (ko mvc sauc par view) un tad vēl ir kods, kas apstrādā requestu (ko mvc sauc par controller) un veic gan datu pieprasījumus, gan arī pēc tam tos attēlo, izmantojot iepriekš nodefinētās funkcijas. šo ideju var norealizēt līdz dažādām pedantiskuma pakāpēm: gan iekšēji baigi strikti nodalīt funkcijas un visus datus vairākkārtīgi padot no vienas funkcijas argumentiem tālāk citai funkcijai (tipa spēlēt volejbolu, piespēlējot/mētājot datus no vienas funkcijas tālāk nākamajai), gan arī visu sadalīt daudzum daudzos failiņos pa atsevišķiem folderīšiem. bet var pieiet arī elastīgāk un mixēt un pat apvienot līdzīgu funkcionalitāti. vot šī mvc implementācija ir tas, ko es saucu par gaumes jautājumu. savukārt, kad es teicu ka "MVC toč ir priekš noobiem", es domāju, ka noobiska ir tieši ļoti cītīga pieturēšanās pie kkādiem priekšrakstiem, ko cilvēks pats līdz galam nesaprot, un kas atbilstošajā situācijā var pat nebūt pareizākā un lietderīgākā

 

ok, lai nebūtu tikai kritizēšana (un lai Jūs varētu pakritizēt arī mani :D:D:D), mans piegājiens ir apmēram šāds:

web applikāciju dalu komponentos (komponents var apvienot vairākus līdzīgus objektus):

1) statiskais kontents (par mums, kontakti, bla bla bla)

2) produkti, kategorijas

3) grozs, pasūtījumi

 

katram komponentam ir

1) datu modulis ar db pieprasījumiem/kverijiem: gan triviāliem select,insert,update,delete, gan advancētākas darbības, kad vienā funkcijā ir vairāki db kveriji

2) ui modulis (priekš site un cms katram savs), kurš turklāt dalās divās loģiskās daļās:

a) ui darbību izpilde (formu apstrāde)

b) ui attēlošana (saformē html un echo)

ui modulis manā izpildījumā izsauc datu moduļa funkcijas: tās, kuras ir nepieciešamas, lai attēlotu konkrēto komponentu/objektu konkrētajā kontekstā

 

kontrole aizņem vismazāk koda: vnk jāizpilda attiecīgā ui darbība un/vai jāparāda attiecīgais kontents

 

thats it! so simple ;)

 

 

lai arī lietoju vārdu "objekts", taču es tikai domāju objektos. funkciju nosaukumus arī rakstu objektorientētā stilā, piemēram:

datu pieprasījumu funkcijas: productSelectItem(), productSelectList(), productInsert()
ui darbību funkcijas: productInsertOp(), productUpdateOp()  // op - ui operation (op galā pielieku tāpēc, lai funkcijas nosaukums atšķirtos no līdzīgām zemāka līmeņa datu pieprasījuma funkcijām. kr4 lai nebūtu naming kolīzijas)
ui attēlošanas funkcijas: productItemEcho(), productListEcho()

man tā vnk ir ērtāk organizēt kodu, kad domāju objektorientēti, taču viss kods anyway ir procedurāli, jo kodēt web applikācijas burtiskā oop sintaksē ir smags overkills, jo oop ir jāraksta kkur vismaz par 20% vairāk koda, lai dabūtu to pašu funkcionalitāti, ko rakstot procedurāli. visu kodu, kas veido web applikācijas funkcionalitāti, var ļoti labi sadalīt pa moduļiem procedurāli (modulis - fails ar līdzīgām funkcijām, pie kam failā var būt vairāki moduļi. tādā gadījumā tos saucu par loģiskiem moduļiem)

 

mācoties taisīt web applikācijas var iekrist dažādās galējības: daļa programmētāju (pārsvarā iesācēji) pieiet pārāk vienkārši un raksta kkādu makaronu kodu, kur viss ir kopā, bet citi, kas jau ir mazliet gudrāki, bieži krīt otrā galējībā un visu nenormāli cenšās abstrahēt caur entajiem abstrakciju līmeņiem, interfeisiem un objektu objektiem, etc. protams, viņi ir krutāki par pirmajiem, jo pirmie vnk nemāk to oop un līdz ar to arī nemāk tik sarežģīti uztaisīt, taču savā "krutumā" tie otrie nepamana, ka ir noobi no viena cita aspekta - tādā ziņā, ka netēmā sarežģī vienkāršas lietas. vajag atcerēties vienu vienkāršu patiesību: web lapa nav nekas vairāk kā vnk strings no <html> līdz </html> (ar DOCTYPE sākumā + vēl ārējie resursi css,js,images,...) un izstrādātāja galvenais uzdevums ir tik vien kā saformēt šo stringu un echo. lai izdarītu tādu pēc būtības vienkāršu lietu, tiešām nevajag pārcensties ar sarežģīšanu... kr4 zelta vidusceļš ftw

 

nju tie bija my 2 cents about mvc and stuff ;)

[codez]

Gribētu redzēt kā procedurālā stilā tiek realizēti ikdienišķi paterni, piemēram, __autoload kopā ar singletona paternu.

 

class LDb extends mysqli{
 private static $instance;

 private function __construct(){
   parent::__construct(DB_HOST,DB_LOGIN,DB_PASS, DB_DB);
   $this->set_charset("utf8");	
   $this->autocommit(false);
 }

 public static function i()	{
   if (!self::$instance instanceof self){ 
     self::$instance = new self;			
   }
     return self::$instance;
   }  

 ...

 

Šāda paterna izmantošanas gadījumā, es varu rakstīt

 

LDb::i() un šī rindiņa automātiski izsauks __autoload funckiju, kur inklūdos LDb klases failu, ja šāda klase nebūs definēta, un izveidos vienu LDb objekta instanci un atgriezīs to un izveidos db konekciju. Otreiz izsaucos šo pašu, viņa atgriezīs jau izveidoto LDb instanci.

Rezultātā, es jebkurā vietā varu rakstīt:

 

LDb::i()->query('SELECT * FROM users');

 

un neuztraukties par to vai esmu jau piekonektējies db vai nē un, ja gadījumā kādā pieprasījumā nav neviena šāda izsaukuma, tad nenotiek lieka konektēšanās pie db.

 

Tas pats attiecas uz elementāru statisku funkciju izsaukšanu:

Piemēram divas bibliotēkas:

 

class LF1 {
 public static function f1()	{
   }  
 public static function f2()	{
   }  
}

 

class LF2 {
 public static function f1()	{
   }  
 public static function f2()	{
   }  
}

 

es varu jebkurā koda vietā rakstīt:

 

LF1:f1() un __autoload funkcija man nodrošinās LF1 klases faila inklūdošanu.

Man nav jāuzstraucās, kuras bibliotēkas ir inklūdotas, kuras nav, jo __autoload automātiski inklūdos šo klašu failus, pirmo reizi pieprasot šo klasi, tādā veidā, ja man freimworkā ir desmitiem klašu, bet man kāda pieprasījuma laikā tiek izmantotas funkcijas tikai no divām, tad man nav jāuztraucās, kuras klases inklūdot, kuras nē, tiks inklūdotas tieši to klašu failu, kurus es izmantoju.

 

Un tie ir tikai elementārākie paterni, kuru var realizēt ar OOP.

Edited March 26, 2010 by codez

[2easy]

njaa codez, oop ir lipīga slimība, bet arī to var izslimot :D

 

1) attiecībā uz pirmo daļu par mysql http://php.lv/f/topic/15781-mysql-vaicajums/page__view__findpost__p__122190

 

ja jau web applikācija vsp izmanto db, tad db konekciju vajadzēs izveidot anyway. tāpēc iekš init() arī izsaucu dbconn() (init() ir funkcija, kurā veicu dažādas applikācijas startup darbības). agrāk gan darīju apmēram kā Tu, ka db konekciju veidoju tikai pirmajā pieprasījumā, bet vēlāk to vairs neuzskatīju par tik labu praksi un novienkāršoju algoritmu :))

 

un katru reizi, kad vajag izpildīt db kveriju, vnkārša go() vietā rakstīt ~4x garāku LDb::i()->query()

tur jau pat zirgam būtu jāsmejās :D:D:D:D:D

nju kā tā var sarežģīt vnk funkcijas izsaukumu!!! tiešām nebiju no Tevis to gaidījis...

 

2) par inklūdošanu. es priekš sevis ieviesu tādu jēdzienu kā komponents, kā gan loģiski, gan fiziski iedalīt web applikācijas kodu, un inklūdoju tikai tos failus, kas tobrīd ir aktuāli/nepieciešami. ir standarta inklūds, kas notiek vienmēr pašā sākumā un inklūdo konfigu un dažādas standarta/lib funkcijas, bet custom komponentu inklūds notiek vēlāk kontrolierī: applikācijas main() funkcijā. lapas adresē jau ir skaidri pateikts, kāds saturs ir jārāda, līdz ar to tiek inklūdots viss nepieciešamais, lai to parādītu...

 

vnk nāk smiekli par to, ka kāds izmanto oop tikai tāpēc, ka php tam ir piekabinājis kkādu autoload, kas pats par sevi nav nekāda oop fīča, bet php fīča :D:D:D

 

anyway ja Tu rakstītu procedurāli, Tev nebūtu tik ļoti uzpūsts/bloated kods un Tev nevajadzētu katru sīkumu likt savā klasē un katru klasi savā failā. Tu varētu vnk inklūdot vajadzīgo komponentu atkarībā no konteksta un tur būtu visas darbam nepieciešamās funkcijas. bet Tu jau pats izvēlējies rakstīt sarežģītāk un tagad arī cīnies ar šo sarežģītību ar tās līdzekļiem. hahaha :P

 

kr4 autoload vsp nav nekāda fīča! tas tika ieviests, lai palīdzētu developeriem cīnīties ar vienu no oop blakusefektiem: daudzām klasēm daudzos failos. tas toč nav nekas tāds, ar ko varētu lepoties

[codez]

ja jau web applikācija vsp izmanto db, tad db konekciju vajadzēs izveidot anyway. tāpēc iekš init() arī izsaucu dbconn() (init() ir funkcija, kurā veicu dažādas applikācijas startup darbības).

Pilnīgas muļķības.

Tā var darīt mazām weblapām, kurām tiešām lieku visa inicializāciju var atļauties katru reizi.

 

Bet, piemēram, normālās aplikācijās dati tiek kešoti, kaut vai ar to pašu memcache un realitātē ir tā, ka pat līdz 90% pieprasījumu neizpilda nevienu mysql kveriju, jo datus iegūst nokešotā veidā, it sevisķi ajaxīgās aplikācijās.

 

un katru reizi, kad vajag izpildīt db kveriju, vnkārša go() vietā rakstīt ~4x garāku LDb::i()->query()

tur jau pat zirgam būtu jāsmejās :D:D:D:D:D

nju kā tā var sarežģīt vnk funkcijas izsaukumu!!! tiešām nebiju no Tevis to gaidījis...

1)Ja vēlies īsi var arī noīsināt uz D::q();, kur q funkcijā ir apvienots singletona paterns un query funkcijas izsaukums no vienīgas db instances.

2)Bet atšķirība tā, ka nav jāuztraucas par to, kad un kur rakstīt db inicializāciju. Piemēram, katrā ajax kontrolerī, kurš varbūt sastāv no dažām rindiņām, nav katru reizi jāraksta "universālā" visu lietu inicializācija.

3)Katrā ajax kontrolerī nav jaraksta n-to lietu inclūdes, kuru funkcijas vai objekti tur tiks izmantoti.

 

 

 

2) par inklūdošanu. es priekš sevis ieviesu tādu jēdzienu kā komponents, kā gan loģiski, gan fiziski iedalīt web applikācijas kodu, un inklūdoju tikai tos failus, kas tobrīd ir aktuāli/nepieciešami. ir standarta inklūds, kas notiek vienmēr pašā sākumā un inklūdo konfigu un dažādas standarta/lib funkcijas, bet custom komponentu inklūds notiek vēlāk kontrolierī: applikācijas main() funkcijā. lapas adresē jau ir skaidri pateikts, kāds saturs ir jārāda, līdz ar to tiek inklūdots viss nepieciešamais, lai to parādītu...

Vienkārši piemērs kontrolerim, kurš atbild uz ajax requestu (/ajax/messages/get), lai iegūtu pēdējos lietotājam sūtītās ziņas ar noteiktā lpp:

class AMessages{
 function get(){
   $ofs=(int)$_POST['ofs'];
   if (LAuth::i()->is_logged()){
     echo '{ok:1,data:'.json_encode(LDb::i()->qf('SELECT * FROM messages WHERE uid=%s LIMIT %s,20'),array(LAuth::i()->id(),$ofs),3).'}'
   } else {
     echo '{ok:0,err:"Not logged"}';
   }
 }
}

Protams, realitātē saziņa ar db būtu ielikta messages modelī un tā vietā būtu MMessages::get(LAuth::i()->id(),$ofs), bet šo es nodemonstrēju šādā veidā.

Nekādu lieku inicializāciju, nekādas uztraukšanās vai kaut kas ir inicializēts vai nē, jo visu nodrošina singleton paternu izmantošana.

Kodā nav neviena inklude, neviena inicializācija, kas ļauj katrā konkrētā vietā uztraukties tikai par konkrētās vietas nepieciešamā uzdevuma izpildi.

Un, ja atgriežamies pie varianta, ka saziņa ar db ir modeļos, tad kad tiks inicializēt db?

sākumā? a, ja nu requestā db vispār nav vajadzīga? modeļa funkcijā? Bet, ja nu tiek izsauktas divas dažādas funkcijas? Divreiz inicializēsi db?

 

 

anyway ja Tu rakstītu procedurāli, Tev nebūtu tik ļoti uzpūsts/bloated kods un Tev nevajadzētu katru sīkumu likt savā klasē un katru klasi savā failā.

Nez kā citiem, bet man ir daudz ērtāk pārskatīt klases, ja katra ir savā failā.

 

Tu varētu vnk inklūdot vajadzīgo komponentu atkarībā no konteksta un tur būtu visas darbam nepieciešamās funkcijas.

Kāpēc inklūdot un inicializēt kaut ko, ja to visu var realizēt automātiski un pie tam kodēšanas procesā neuztraukties, vai esi visu inklūdojies vai esi visu inicializējis, vai neesi uz vienkāršu ajax requestu inicializējis un inklūdojies par daudz lietu.

 

 

 

Vienkārši uzraksti savu alternatīvu šim vai iepriekšējā posta kodam, kā tu to pašu realizētu proceduālā formā.

Edited March 26, 2010 by codez

[2easy]

es jau uzrakstīju, kā man patīk kodēt :)) vēlreiz to pašu netaisos paskaidrot...

 

ja vajadzētu kko optimizēt dēļ performances, tad es arī konkrētajā situācijā izdomātu, ko darīt. zinu, ka uz mana pc db konekcijas izveidšana paņem nepilnas 2 milisekundes, kas ir relatīvi ļoti daudz, salīdzinot ar citām "sīkām" darbībām. lai arī man interesē koda optimizēšana un es mēru performanci - kaut vai nupat pavisam svaigs piemērs http://php.lv/f/topic/16057-str-replace-un-rand-savienosana-tada-ka-cikla/page__view__findpost__p__125165 taču man nav pieredzes tādu patiešām lielu un noslogotu projektu izstrādē. anyway, es pielāgotos on demand... bet savādāk kodētu tā, kā man ir ērti ;) un tas arī ir message, ko gribēju pateikt

 

es šeit vnk reklamēju to, ka vajag domāt arī pašiem un kritiski novērtēt dažādas web izstrādes tendences (sry ja aizvainoju kādu vai kāda ieradumus). tb ideja ir neskriet līdzi visam un visiem pēc kārtas. dažas zivis peld pret straumi un pareizi dara :D:D:D

[codez]

es pielāgotos on demand... bet savādāk kodētu tā, kā man ir ērti ;) un tas arī ir message, ko gribēju pateikt

 

Es savukārt gribu pateikt, ka tā programmēt ērti ir tikai tev un nevis tāpēc, ka tā ir de facto ērti programmēt, bet tāpēc, ka tas ir tavs ieradums.

Tur, kur esi tagad tu, es biju pirms gadiem diviem. Man vajadzēja vairākus mēnešu, lai pārvarētu savus ieradumus un nomainītu vienu paradigmu pret otru.

Bet varu pateikt, ka pēc tam, kad apguvu to, ko apguvu, atpakaļ vairs skatīties netaisos un arī tie cilvēki, kuriem šo esmu iemācījies saka, ka atpakaļ vairs skatīties nav vērts.

 

 

es šeit vnk reklamēju to, ka vajag domāt arī pašiem un kritiski novērtēt dažādas web izstrādes tendences

Tieši to jau mēs te darām, kritiski vērtējam viens otra web izstrādes tendences - abpusēji.

[2easy]

Tur, kur esi tagad tu, es biju pirms gadiem diviem. Man vajadzēja vairākus mēnešu, lai pārvarētu savus ieradumus un nomainītu vienu paradigmu pret otru.

lol, tur kur esi tagad tu, es biju pirms gadiem 5 :D:D:D

 

taču es nemēģināju pārvarēt ieradumus. es dabiski jutu, ka kkas ir jāmaina, ka kkas nav tā kā vajag. es runāju par oop. es patiešām mēģināju atrast tam pielietojumu, bet katru reizi sanāca, ka procedurāli ir ātrāk un vnkāršāk. n-tās reizes esmu filozofējis un mēģinājis skatīties uz lietām pēc būtības, kas ir kas. kas ir izdevīgi un kas nav. ko vajag darīt un ko nē. galu galā par oop man salikās šāds priekšstats: tas ir bērnu trīsritenītis (atšķirībā no divriteņa tam ir extra ritenītis drošībai, lai nevar apgāzties, taču šī fīča nāk klāt uz ātruma rēķina...)

 

tb oop ir domāts muļķu drošai programmēšanai. pirmos gadus, kamēr programmētāji vēl mācās kodēt, labāk tiem uzlikt visādus ierobežojumus jau pašā programmēšanas valodā, lai iemācītu disciplīnu un samazinātu muļķīgu kļūdu iespējamību. tāpēc pašā programmēšanas valodā ir salikti visādi ierobežojumi, tipa private/protected etc. viss ir baigi explicitly un baigi kārtīgi. protams, normāli/sakarīgi organizēt savu kodu var jebkurā valodā, taču oop to vnk naturāli brutāli uzspiež! taču tādiem totalitāriem piegājieniem ir vairāki drawbacki. neskaitot to, ka kodējot oop neizbēgami ir jāraksta kods, kas nerada nekādu pievienoto vērtību, bet ir tīri paša koda menedžējošais kods, ir vēl citas problēmas: ierobežojumi. tb citas klases funkciju šajā klasē var izsaukt tikai tad, ja šī klase ir mantota (extend). inheritance tiek pasniegta kā sazin kkāda tur baigā oop fīča, bet patiesībā tas ir oop design flaw. un lai tiktu vaļā no ierobežojumiem, tomēr nākas meklēt veidu, kā to atļaut, un tad arī ir inheritance ftw. taču no mārketinga viedokļa oop problēmas tiek pasniegtas tieši otrādi: ka aizliegšana ir baigā fīča :P kr4 man oop sintakse jau pašos pamatos liekas wrong priekš profesionālas programmēšanas. mācoties vispār kodēt, oop vēl ir ok, bet jo ātrāk tam tiek pāri, jo labāk :)) oop filozofija man gan patīk, jo es arī uz daudz ko (bet ne uz visu) skatos kā uz objektiem, taču vairs nekodēju oop sintaksē dēļ pārāk lielā liekā koda overhead un nevajadzīgiem (priekš manis) ierobežojumiem. bet nju tas ir tikai mans humble opinion par oop ;) ymmv

[2easy]

un kur tad palika visi lielie oop "kingi", ka nenāk aizstāvēt savu oop???

kkāds 2easy klaji apdirš oop, un neviens oop fans (izņemot codez) pat neiepīkstas? :D:D:D

 

nee nju labi, viens no maniem aprēķiniem, mēģinot piešķilt diskusijai fleimu, bija dabūt kkādu feedback, uzzināt kko jaunu, kādu krutu oop pielietojumu, ar ko es varētu kko izdarīt ātrāk/labāk nekā procedurāli. es patiešām joprojām ceru, ka kkad atklāšu tās oop pērles, ar ko tas kkādos aspektos varētu būt pārāks par parastām funkcijām. es domāju kkādu reālu pievienoto vērtību to get the job done faster/easier. bet līdz šim vnk kkā tā ir sanācis, ka procedurālā programmēšana liek iekšā oop vienos vārtos :P

 

vai varbūt vnk neviens neuzskata par vajadzību mēģināt iet kko pierādīt kkādam 2easy? ;)

 

ehh, laikam nobody cares... :D

Edited March 26, 2010 by 2easy

[Mr.Key]

nu kas tur ko aizstāvēt - maziem viena cilvēka projektiem strukturēta pieeja droši ka ir ātrāka gan no izstrādes, gan no runtime resursu patēriņa viedokļa.

 

lieliem projektiem - diez vai. pirmkārt, izstrādes sarežģītība pieaugs ģeometriskā progresijā ar katru jaunu koderi vai jaunu fīču, arī ātrdarbību tur risina savādāk (cache, cache, cache).

 

Extendošanu nosaukt par design flaw ir diezgan avantūriski, tāpēc arī neviens nopietns oop fans laikam neiesaistās.

[2easy]

Extendošanu nosaukt par design flaw ir diezgan avantūriski

nu jā, tev taisnība. mazliet neprecīzi izteicos. kr4 design flaw ir nevis pati extendošana, bet oop uzliktie ierobežojumi, kas tādi ir by design. pp (procedurālā programmēšanā) nav nekādu problēmu izsaukt vajadzīgo funkciju, taču oop ir obligāti jāuztaisa klases instance un tad tikai var kko sākt darīt (statiskās metodes es nepieskaitu, jo tā ir pp). tā kā programmai vajag izsaukt daudz dažādu funkciju atkarībā no vajadzības, tad dažreiz tas ir baigi neērti, ka kko nevar izdarīt uzreiz. tad nu extendošana nāk glābt oop un atļauj vismaz izsaukt tās funkcijas, kuras šī klase manto :))

 

ok, tas ka lielu projektu izstrādē tamlīdzīgiem ierobežojumiem parādās tas, ko es saucu par "pievienoto vērtību", to jau es neapstrīdu. taču tā oop pievienotā vērtība ir tīri koda menedžmenta ziņā un nekādi neveicina produktivitāti tiešā veidā. tas ir kā birokrātija valstī: viskautko aizliedz (ko vajag un ko nevajag), bet savādāk nevar, jo tad sāktos pilnīgs bezpreģels... :D:D:D

 

vispār uz lietām var paskatīties ļoti dažādi. kādam var likties, ka es pasaku kko avantūristisku, bet citam tas var uzlīt kā auksts ūdens uz galvas. es tikai cenšos veicināt veselīgu kritisku domāšanu/pieeju lietām. anyway, visu ko var uzkodēt ar oop, var uzkodēt arī ar pp, jo kompilējot/interpretējot oop kodu, tas tāpat galu galā translējas uz mašīnkodu, taču tajā līmeni procesoram padod instrukciju un padod datus (vai adresi, kur ir dati) un cpu to izpilda. tā ir tīra pp

Edited March 26, 2010 by 2easy

[2easy]

weblapu kodēšana arī ir vnkārša jau pēc definīcijas, kamēr neierodas visādi oop fani un to nesarežģī :D

 

ok, par to kopīgo un atšķirīgo funkcionalitāti...

tur vsp ir 3 līmeņi/iedalījumi:

1) standarta/lib funkcijas, kas ir 100% vienādas visos saitos

2) funkcijas, kas pamatā ir vajadzīgas vienmēr, taču var nebūt pavisam standarta - dažos saitos tās ir nedaudz custom. tb ir mazliet jāpielāgo atkarībā no situācijas

3) pilnīgi custom funkcijas, kas ir tikai un vienīgi konkrētajā saitā

 

kā kodu organizēt (sadalīt pa moduļiem/failiem), tas jau tālāk ir gaumes jautājums

anyway ir vēlams izvēlēties vienkāršāko risinājumu/algoritmu konkrētajam uzdevumam un censties nesarežģīt šīs vienkāršās lietas

 

kiss

Edited March 29, 2010 by 2easy

[php newbie]

īstenībā bija diezgan interesanta diskusija par to oop, bet tagad jau nevaru to atrast, laikam "izmoderēja". Dīvaini ka neviens tā arī nenolika to nekauņu 2easy pie vietas :D

[2easy]

domā šo? http://php.lv/f/topic/15535-interesanta-diskusija-par-mvc/page__view__findpost__p__125068

 

sākās kā mvc diskusija, bet panesās par oop... :D:D:D

ok, pārmāciet mani lūdzu, lūdzu!!! ;)

 

plz, good examples studijā! kā ar oop var izdarīt ātrāk un vienkāršāk, rakstot mazāk kodu, nekā ar pp

 

 

un tad jau pie reizes arī senāki mani izteikumi/izsmiekls par oop:

http://php.lv/f/topic/15568-problemas-ar-extends-class/page__view__findpost__p__119939

http://php.lv/f/topic/14864-klases-vs-funkcijas/page__view__findpost__p__114794

http://php.lv/f/topic/15423-noderigas-funkcijas/page__view__findpost__p__118663

Edited March 29, 2010 by 2easy

[codez]

plz, good examples studijā! kā ar oop var izdarīt ātrāk un vienkāršāk, rakstot mazāk kodu, nekā ar pp

 

Es jau tev nodemostrēju kodu, tu pretī pp kodu nedevi, pieņemu, ka piekāpies.

[2easy]

vai bez codez ir vēl kāds drosminieks? ;)