OOP vs PP vs ?

[Aleksejs]

Pēdējā laikā tiek cilāta tēma OOP vs PP, kas pēc būtības ir labi. Taču tā tiek cilāta tēmās, kurās šī diskusija neiederās, kas ir slikti.

Lūgums cīnītājiem izcīnīt cīņas šajā jautājumā, izmantojot šo tēmu. :)

Visas (manuprāt) šai diskusijai vairāk piemērotās tēmas tiks pārnestas uz šejieni.

[2easy]

neee! stop! no! Aleksej, tu atkal izjauksi dabisko diskusijas attīstību. ir svarīgs konteksts, kādā mēs runājam par šīm lietām!!!

 

tu pārāk centies visu sakārtot, bet šajā gadījumā tu izjauc diskusiju...

tāpat visu pp vs oop tu nesavāksi vienā vietā. anyway no tā labākajā gadījumā iznāks tikai kkāds bezkonteksta biezenis, līdzīgi kā ir darba sadaļas offtopikā

 

kr4 tu pārcenties. liec atpkaļ tos postus, kur tie bija!!! ;)

Edited March 29, 2010 by 2easy

[Aleksejs]

Ej sūdzies partorgam!

[2easy]

ehh "kad es būšu admins, un tu būsi spameris... tad es ar tev tā izdarīšu" :D:D:D

 

 

un paldies, ka esi izveidojis jau visus 3 manus topikus šajā forumā! ;)

Edited March 29, 2010 by 2easy

[Aleksejs]

Būtu tomēr interesanti redzēt +- vienkārša projekta (nu teiksim bloga) realizāciju OOP stilā un PP stilā.

Un pēc šīs gatavās realizācijas, būtu interesanti salīdzināt, cik daudz koda izmaiņas bija nepieciešamas, lai izveidotu nākošo versiju ar:

*) Vienu būtisku izmaiņu Datu arhitektūrā

*) Vienu būtisku izmaiņu biznesa loģikā servergalā

*) Vienu būtisku izmaiņu biznesa loģikā klientgalā

*) Vienu būtisku izmaiņu klientgalā dizainā

 

Bet kam tad ir laiks ar tādām lietām ņemties?!

[2easy]

tur jau tā lieta, ka pp un oop ir tikai koda pieraksta sintakses, un ar pp ekvivalentu funkcionalitāti var uzkodēt ar mazāku koda apjomu nekā ja to pašu pieraksta oop stilā. un fīču pievienošana kkad vēlāk nav atkarīga ne no viena no šiem stiliem (pp, oop vai whatever), bet gan no tā, kā ir organizēts kods, tobish no applikācijas arhitektūras, kurai tādi pp vai oop pilnīgi pofig (tās jau ir tehniskās nianses). visu darbu tāpat dara pp funkcijas vai oop metodes. vienkāršība/sarežģītība slēpjas tikai un vienīgi kā tiek izvietots/organizēts applikācijas kods/funkcionalitāte/funkcijas/datu plūsmas, savstarpējās dependencies un tamlīdzīgas lietas... un ar konkrētu paradigmu (pp vai oop) tam nav nekāda sakara. tas ir atkarīgs no programmētāja, kurš prot domāt visas sistēmas līmenī. kr4 tas vairāk ir sistēmanalīzes jautājums, nevis pp/oop

 

tāpēc visa šī "pp vs oop" cīņa ir tikai farss :D:D:D (nopietni)

Edited March 29, 2010 by 2easy

[Aleksejs]

Tā ir tikai teoretizēšana no Tavas puses šobrīd bez praktiska vārdu seguma. ;)

[2easy]

labi, ka taviem vārdiem ir biezs segums ^^

[codez]

2easy, ja tupini apgalvot savu, tad vismaz sāc atbildēt ar pp kodiem.

 

Vēl viena lieta. tev pieņemsim vienā projektā ir bibliotēkas, kuras satur pp funkcijas, bet tu gribi izmantot kādu bibliotēku citā kodā. Tev principā ir jāpārbauda vai kāda jau no esošajām funkcijām pēc nosaukuma nepārklājas ar tavu nupat iekopēto bibliotēku, kamēr OOP ir jāpārbauda tikai klases, lai gan manā MVC pat tas nav iespējams, jo klases nosaukumam jābūt vienādam ar faila nosaukumu, lai __autoload varētu ielādēt vajadzīgo klasi. OOP nodrošina tādu kā namespace.

[2easy]

tas ka Tu, codez, ar __autoload() pieminēšanu pacēli tēmu par applikācijas inicializēšanas automatizēšanu un optimizēšanu, tas ir labi. taču tās lietas ir jāsalīdzina uz konkrētas nelielas veselas testa web applikācijas (apmēram kā Aleksejs ieteica), nevis uz viena atsevišķa koda fragmenta

 

applikācijas inicializēšanu un include var dažādi noautomatizēt. kaut vai taisīt automātisku pārbaudi ar function_exists() un include on demand. arī funkcijas var izsaukt automātiski: $f = 'blabla'; $f();

biežāk gan failu ar vajadzīgajām funkcijām inkludo atkarībā no konteksta: lapas adreses un padotajiem get/post parametriem. un to dara applikācijas init laikā, lai pēc tam nevienai funkcijai vairs nav "jādomā", vai kko vēl vajag inkludot vai nē. turklāt tā kā ar pp sanāk daudz mazāks un kompaktāks kods, tad arī inklūdot vajag mazāk, un php parserim arī ir mazāk koda jāparsē :))

 

anyway klašu failu autoinklūds ar __autoload() nav nekāda oop fīča, bet tikai vēl viens php include mehānisms

 

 

 

savukārt filozofija un prakse attiecībā uz tīru oop: objekta dati (property:value) pēc būtības ir asociatīvs masīvs (key:value), un ja šim masīvam vēl varētu piekabināt funkcijas ("metodes"), tad sanāktu objekts :)) (un tante būtu tramvajs :D)

 

// pp
$a = array();
objDoSomething($a, 123);

// oop
$o = new Obj()
$o->doSomething(123);

kodējot procedurāli, man kolīzijas nosaukumos nerodas, jo funkcijas saucu "oop stilā": funkcijas nosaukums sākas ar "objekta" nosaukumu. piemēram, visas timer funkcijas http://php.lv/f/topic/16057-str-replace-un-rand-savienosana-tada-ka-cikla/page__view__findpost__p__125165 sākas ar "tmr" (saīsinājums vārdam "timer")

 

tāpēc vajadzība pēc atsevišķa namespace nav aktuāla

 

ok, uzrakstīšu to pašu funkcionalitāti gan pp, gan oop

// šī ir vispārīga/generic palīgfunkcija un var noderēt vēl kkur, tāpēc to nav vērts bāzt iekšā kādā konkrētā klasē
function tmu() {list($nSecU, $iSec) = explode(' ', microtime()); return $iSec + $nSecU;}

// pp
$gnTm = 0;
function tmrSet() {global $gnTm; $gnTm = tmu();}
function tmrGet() {global $gnTm; return tmu() - $gnTm;}
function tmrEcho($sInfo = '') {printf('%s%.4f<br />', $sInfo, tmrGet());}

// oop
class Tmr {
private $nTm = 0;
public function set() {$this->nTm = tmu();}
public function get() {return tmu() - $this->nTm;}
public function show($sInfo = '') {printf('%s%.4f<br />', $sInfo, $this->get());}
}

// testējam... skaitam līdz miljonam un uzņemam laiku ar katru taimeri: pp & oop (pats laiks te nav svarīgs, jo tam for ciklam nav nekāda sakara ar pp/oop)

// pp
tmrSet();
for ($i = 0; $i < 1000000; $i++);
tmrEcho();

// oop
$oTmr = new Tmr();
$oTmr->set();
for ($i = 0; $i < 1000000; $i++);
$oTmr->show();

pirmkārt, šis piemērs lieliski demonstrē to, ka oop var būt vairāk kolīziju funkciju nosaukumos nekā pp. ja pp variantā es varēju lietot vārdu "echo" iekš tmrEcho(), tad oop gadījumā man to vajadzēja pārsaukt uz "show", lai izvairītos no kolīzijas ar php iebūvēto funkciju (valodas konstrukciju). un ievērojiet, ka php ir tūkstošiem funkciju! tāpēc kodējot pp un liekot funkcijas nosaukuma prefiksā atbilstošo "objekta" nosaukumu, Jums par kolīzijām un namespace vsp nebūs jādomā. kr4 vajag domāt objektorientēti, piešķirt nosaukumus objektorientēti, organizēt kodu modulāri, taču NEkodēt oop sintaksē! :D

 

bet tagad saldais ēdiens...

 

funkcionalitātes koda apjoms baitos un rindiņu skaits:

pp: 192 byte, 4 rindiņas

oop: 217 byte (+13%), 6 rindiņas (+50%)

 

testa koda apjoms baitos un rindiņu skaits:

pp: 56 byte, 3 rindiņas

oop: 84 byte (+50%), 4 rindiņas (+33%)

 

lūdzu, oop pilnīgi nevajadzīgais bloated overheads visā savā skaistumā! :D:D:D

tas ir tas, ko es saucu par "pp liek iekšā oop vienos vārtos"

 

kr4 ar oop Jūs iegūstat daudz apjomīgāku kodu, turklāt pilnu ar dažādiem ierobežojumiem (private/protected), kurus jums vēl pašiem ir jākodē! :P un pēc tam vēlreiz pašiem sev jāatļauj (jāmanto ar extend :D). tas viss maigi izsakoties ir neērti un es šādu muļķīgu tukšgaitas darbošanos un beztolka pašmenedžēšanu neatbalstu. turklāt pati ideja pārāk iekapsulēt datus, sakausējot tos kopā ar metodēm, rada pārāk statisku/masīvu kodu. tas ir apmēram tāpat kā kodēt lapas layoutu ar tabulām tā vietā, ka to 2x ērtāk un elastīgāk var izdarīt ar css. "css layout vs table layout" ir vēl viena tamlīdzīga "cīņa". labi vismaz, ka tur tauta ir saprātīgāka un atzīst, ka css ir krutāks. bet oop fanus tā oop muša ir tik stipri sakodusi, ka pat rādot klaji kliedzošus piemērus, tik un tā tie ietiepīgi turpina uzskatīt, ka oop ir labāks :D:D:D bet nju katram savs...

 

vsp man priekš sevis ir ļoti skaidra definīcija vārdam "labāks". tas ir mazāks/kompaktāks ātrāk uzrakstāms/menedžējams kods

1) kompaktumu es panāku ar pp + labu nosaukumu saīsinājumu izvēli (common/standard abbreviations)

2) savukārt menedžējamību es panāku, pārdomāti sadalot applikācijas funkcionalitāti pa dažādām funkcijām, funkcijas sagrupēju pa moduļiem un moduļus pa failiem. un šai koda organizēšanai/arhitektūrai nav nekāda sakara ar pp/oop (kā jau uzrakstīju #21 postā)

 

tobish man ir gan skaidrs mērķis, gan skaidri līdzekļi (darba metodoloģija), gan arī skaidrs pamatojums, kāpēc un ar ko konkrētā izvēle ir labāka

 

vispār es šo visu rakstu ne jau priekš sevis, bet priekš Jums. es zinu, ka ir daudz iesācēju, kas vēl tikai brīnās un mācās kodēt. un viņi grib zināt "kā ir labāk" un "kā ir pareizi/āk". un tad daži nedaudz pieredzējušāki iesācēji viņiem mēdz ieteikt oop, tipa jo "tā ir krutāk", "tā ir modernāk", "visi tā dara" un cenšas pamatot savu ieteikumu vēl ar citiem tamlīdzīgiem tikpat nenopietniem argumentiem. manuprāt, oop ir tikai un vienīgi treniņam. tā ir vnk filozofija par datu ciešu apvienošanu ar šo datu apstrādes funkcijām (kuras oop sauc par metodēm). tā dažkārt ir izdevīgi domāt, un iespējams, mācoties kodēt, tā pat ir labi domāt, taču praksē visu kodēt oop sintaksē sanāk tāds koda overheads, ka maz neliekās. tāpēc profesionāli programmētāji (protams, ne jau visi) uz oop skatās ar smīnu. anyway, domājiet paši, kas jums ir izdevīgi. pārbaudiet konkrētu kodu vienā un otrā veidā. domājiet ar savu galvu un izdariet secinājumus...

Edited March 29, 2010 by 2easy

[Mr.Key]

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

[codez]

Tagad pārtaisi savu PP piemēru tā, lai viņs izpildītu visas tās funkcijas, kuras izpilda OOP piemērs, piemēram var palaist vairākus taimerus.

 

 

Bet, ja nu paliekam pie viena taimera, tad:

 

class Tmr {
 static $nTm = 0;
 function set() {self::$nTm = tmu();}
 function get() {return tmu() - self::$nTm;}
 function show($sInfo = '') {printf('%s%.4f<br />', $sInfo, self::get());}
}

 

188 simboli

 

Tmr::set();
for ($i = 0; $i < 1000000; $i++);
Tmr::show();

 

56 simboli

 

 

taču tu piemirsi vienu lietu savā PP kodā.

Tev to library nāktos inklūdot, tā, ka vēl klāt nāk include

 

include '../lib/tmr.php';
tmrSet();
for ($i = 0; $i < 1000000; $i++);
tmrEcho();

 

Kamēr OOP variantu smuki apstrādā autoload funkcija.

Pie tam OOP piemēra, ja man pēkšņi vajag taimeri, es vienkārši raktu Tmr:set();, neuztraucoties, vai taimera bilbiotēka man jau ir inklūdota vai nav.

Pat šādā vienkāršā piemēra OOP ieliek PP, bet 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.

[bubu]

2easy: Koda kvalitāti mēra rindiņās un baitos? wtf? Tu esi programmētājs vai dumš projekta vadītājs?

[2easy]

Tu esi programmētājs vai dumš projekta vadītājs?

dumš spameris :D

[Kavacky]

Koda mērkaķu pavēlnieks, kur ka tik iet, bet ātrāk gatavs un var dot nākamo darbu. :D