OOP vs PP vs ?

[2easy]

Rezumē - labāk pārliecināts PP programmētājs, nekā nepārliecināts OOP programmētājs :)

jebkurā gadījumā, izvēlies savu nostāju un tad pārliecinoši bliez tik uz priekšu. un tu redzēsi, cik daudz cilvēku, kuriem nav pašiem sava viedokļa, tev noticēs tikai tāpēc, ka tu pats esi 200% pārliecināts par sevi :D:D:D

[2easy]

starp citu, codez, pilnīgi pareizi, ka šajā gadījumā bija jālieto static mainīgais ;)

un labi, ka neļauj man tik ļoti apcelt oop, bet nāc to aizstāvēt. būtu vēl citi no tevis mācījušies un arī tā darījuši

 

tomēr lai kā tu censtos, "static" keywordiņš nozīmē pp pēc būtības (parasts procedurālais kods ir ielikts iekšā klasē, nedaudz pieregulējot sintaksi oop stilā). un tā kā funkcijas arī tu izsauc kā statiskās metodes, tad tu šobrīd nodarbojies ar pp (tiesa gan tas ārēji ir nomaskējies kā oop). līdz ar to pats parādīji, kā ar procedurālo pieeju var nooptimizēt oop kodu. tiešām malacis!!! ja jau oop piekritēji savā oop kodā sāk lietot pp paradigmu, kas var būt vēl labāks :D:D:D kr4 visu izdarīji manā vietā... :P

 

anyway oop tikai cenšas radīt ilūziju, ka pārāk cieši apvieno datus un metodes. bet reāli tas ir pārāk strikts ierobežojums un oop ir pilns ar visādiem workaroundiem, kā piemēram extend un static, lai mīkstinātu šos ierobežojumus un palaistu tos vaļīgāk. kr4 strict oop fails by design... :D:D:D

 

starpība par labu OOP pieaug līdz ar koda arhitektūrisko sarežģītību, kad sāk parādīties jēga lietot dažādus populāros paternus

par šo mēs vēl pacīnīsimies pie kādas mazāk triviālas "pp vs oop" applikācijas. taču lai cik jautri te forumā nebūtu ar jums pļāpāt un strīdēties, šobrīd ir svarīgākas lietas ko darīt...

 

taču attiecībā uz šo tēmu es noteikti varu teikt "i'll be back"

Edited March 29, 2010 by 2easy

[v3rb0]

function tmrSet() {global $gnTm; $gnTm = tmu();}

globālis + kad vēl viens tāds scripta simbolu skaitītājs savā f-jā fzdSt() izmantos globāli $gnTm, tad stundu gļuku meklēsiet :>

[2easy]

globālis + kad vēl viens tāds scripta simbolu skaitītājs savā f-jā fzdSt() izmantos globāli $gnTm, tad stundu gļuku meklēsiet :>

un protams ir cilvēku kategorija, kuri meklē un prot izdomāt problēmas tur, kur viņas nav

 

1) šādi globālie mainīgie ir ļoti, ļoti maz. patiesībā arī tos pāris, kas ir, es varēju ielikt vienā globālā masīvā un tad vsp būtu tikai viens vienīgs globālais mainīgais

2) svešu kodu vispirms paskatās un pārbauda. īpašas nepieciešamības gadījumā to var analizēt arī automātiski ar custom parseri

[2easy]

nju cmon, cmon, kur vēl ir kāds, kuram ir ko teikt??? :D:D:D

aktīvāk lūdzu izsakieties ;)

 

pagaidām vienīgie argumenti par labu oop ir:

1) __autoload(). tā, protams, ir fīča un tāpēc tik cītīgi tiek atkārtota, bet tam nav nekāda sakara ar oop. tas vnk ir veids, kā automātiski inklūdot failu

2) namespace. arī ir fīča, taču funkciju prefixi tāpat visu lieliski atrisina

3) mistiski solījumi, ka pieaugot applikācijas sarežģītībai oop parādīsies kkādi ieguvumi. wtf??? ja jau oop sarežģī pat vnkāršas lietas, tad taisot kko patiešām sarežģītu, oop visu vnk piebeigs :D:D:D

4) ... <- šeit Jūs varat papildināt :P

 

pagaidām izskatās, ka šī tēma ļaus paņemt pie dziesmas visus "Koda dievus" vnlaicīgi :D:D:D vai varbūt te ir arī kāds procedurālais koda dievs? ;)

Edited March 29, 2010 by 2easy

[codez]

tomēr lai kā tu censtos, "static" keywordiņš nozīmē pp pēc būtības (parasts procedurālais kods ir ielikts iekšā klasē, nedaudz pieregulējot sintaksi oop stilā). un tā kā funkcijas arī tu izsauc kā statiskās metodes, tad tu šobrīd nodarbojies ar pp (tiesa gan tas ārēji ir nomaskējies kā oop). līdz ar to pats parādīji, kā ar procedurālo pieeju var nooptimizēt oop kodu. tiešām malacis!!! ja jau oop piekritēji savā oop kodā sāk lietot pp paradigmu, kas var būt vēl labāks :D:D:D kr4 visu izdarīji manā vietā... :P

 

Kādas markas kapronu pīpē?

[Aleksejs]

Es jau savu pateicu - manuprāt, bez netriviāla praktiska projekta reālas implementācijas abās paradigmās, šai sarunai pietrūkst empīrisko datu uz kuriem tad arī balstīt secinājumus. Šeit nav runa vien par programmēšanu kā tādu, bet gan par to, kāda tipa paradigma vieglāk uztverama un kurā vieglāk orientēties konkrētiem cilvēkiem un cilvēku grupām, kurām jāveic konkrētais uzdevums. Eksistē cilvēku grupa, kurai vieglāk ir OOP un eksistē cilvēku grupa, kurai vieglāk PP.

 

Aktuālie jautājumi ir:

*) cik viegli ir atkalizmantot komponentes konkrētā projekta ietvaros un citos projektos,

*) cik viegli projektu sadalīt vairākās daļās pie kurām paralēli varētu strādāt vairāki programmētāji un vienoties par iekšējiem interfeisiem

*) cik viegli projekta sastāvdaļas testēt kā atsevišķi tā arī kopā un veikt trasēšanu

*) cik viegli projektu nodot tālākai uzturēšanai citiem

*) cik viegli projektā veikt izmaiņas (ja pie projekta tiek ilgstoši strādāts ir ļoti interesanti pavērot mainīto rindiņu daudzumu un šī daudzuma attiecību pret kopējo rindiņu skaitu)

*) cik viegli nodot uz āru saskarni, caur kuru ārējie projekti var apmainīties ar datiem

*) cik efektīvs ir radītais kods - cik viegli ir optimizēt tos 20% koda, kas rada 80% slodzi

 

Kuram pietiek laika, lai šo visu izanalizētu? Vai tas, ka šai personai vai personu grupai būs lielāki panākumi, izmantojot paradigmu X, nozīmē, ka paradigma Y nav tik laba šajā gadījumā, vai tomēr to, ka šī cilvēku grupa bija spēcīgāka X un vājāka Y?

[2easy]

Kādas markas kapronu pīpē?

Veco labo PSRS

Edited March 29, 2010 by 2easy

[2easy]

Aleksej, tu nosauci kkāda haizivs izmēra projekta prasības/parametrus. taču jebkurā gadījumā es domāju, ka cilvēciskais faktors šeit ir baigi izšķirošais. labi uzkodēt var gan tā, gan tā (pp/oop). galvenais, ka pasūtītājs saņem kvalitatīvu strādājošu produktu un saprātīgā laikā par konkurētspējīgu cenu. viss pārējais ir tehniskas nianses...

[2easy]

labi, es šovakar vairs nevaru parakstīt. man jau no smiešanās sāp vaigi un kakls :D:D:D

 

have a nice night... ;)

[Aleksejs]

Es nevienu prasību nenosaucu - es nosaucu lietas pēc kuru esamības/neesamības vienkāršības/sarežģītības nosaka, cik efektīva ir konkrētā pieeja (atkarībā no tā, kādā lomā mēs esam mums ir svarīgas pilnīgi citas no šīm lietām). Nekad nav tā, ka projekta prasības nemainās. Nekad nav tā, ka nākošā projekta prasības (pat ja tie ir līdzīgi) ir tādas pašas kā iepriekšējam. Līdz ar to arī rodas tā atšķirība.

[rATRIJS]

1) kā ta nav sakara ar OOP, ja to izmanto tieši OOP nevis procedurālā programmēšana :D

2)

OOP

class DoCoolStuff {
 public function do() { /* te tiek darītas mega foršas lietas */ }
}

class DoEvenCoolerStuff extends DoCoolStuff {
 public function do() { /* te tiek sadarīts vēl kaut kas mega interesants */ parent::do() /* varam padarīt vēl kaut ko */ }
}

class DoMegaUberSuperCoolStuff extends DoEvenCoolerStuff {
 public function do() { /* te vnk acis izsprāgst no foršuma */ parent::do() /* nolaižam tvaiku no foršuma */ }
}

$the_stuff_maker = new DoMegaUberSuperCoolStuff();
$the_stuff_maker->do(); /* your mind is blown away by this point */

 

Procedurāli (re - šis ir tik nepopulāri, ka pat saīsinājuma šamam nav)

function do_cool_stuff_do() { /* šoreiz iztikšu bez komentāriem, jo procedurālis neko kūl nevar ^_^ */ }

function do_even_cooler_stuff_do_cool_stuff_do() { /* can you see where I'm going with it? */ do_cool_stuff_do(); /* smiekliņš */ }

function do_mega_uber_super_cool_stuff_do_even_cooler_stuff_do_cool_stuff_do() { /* this is pretty fucked up ^_^ */ do_even_cooler_stuff_do_cool_stuff_do() /* next level = FAIL */ }

do_mega_uber_super_cool_stuff_do_even_cooler_stuff_do_cool_stuff_do() /* this isn't very cool any more... */

 

Tas ir ja mēs ievērojam konvencijas. Un to mums vajadzētu darīt, ja ar kādu strādājam kopā (vai vēlamies pēc n gadiem šo to pamainīt)

 

3) IMO codez lieliski parādīja dažādu patternu izmantošanu, kas atvieglo un padara skaidrāku programmēšanas darbu

 

Runājot par globālajiem variabļiem. Reiz sanāca mega gļuks, kad wordpresā kāds variablis pēkšņi ieguva random vērtības. Pagāja neliels laiciņš kamēr iedomājos globālos variabļus. Tā arī līdz šim brīdim nesapratu, kā tas gadījās konkrētā koda scope'ā. Tā kā nevajag noliegt kolīzijas :)

 

Pareizi ir izmantot pareizos tūļus, pareizās vietās. Man nav nekas pret procedurālo programmēšanu, bet IMO lieliem projektiem OOP ir labāks. Tieši menedžēšanas ziņā. Pie lieliem projektiem tu reti kad strādāsi viens un kods, kas tev liek pareizi visu strukturēt ir tieši laikā. Kā arī OOP, IMO daudz ko palīdz automatizēt. Tieši visa extend'ošana un __autoload + magic klašu metodes.

[2easy]

zinātnieki ir pierādījuši, ka oop ir labāks par pp

 

(drīzumā tiks papildināts...)

 

 

 

april april :P