laacz, man liekas ka lietojam! http://www.bbc.co.uk/radio1/onelife/fun/health/excess/drop_test.html

Inheritēt p#$%i gan nevaig :) Ar 100% pārliecību varu teikt - nevaig kautko izmantot tikai tapēc ka tas ir kruta. OOP konceptam ir jau ja nemaldos kādi 20 gadi. Ja Tev vajag pārtaisīt sarkanu par kautkādu tur apakšklasi, tad jau protams no tā liela jēga nav. Cik es savā praksē esu saksāries ar OOP, tas rada iespēju projektēt izstrādāt un testēt liela apjoma projektus daudz ērtāk nekā ne OOP gadijumā. Un vēlreiz - tas ir koncepts (protams mūsdienās tam ir ntās realizācijas utt., bet tas nemaina lietas būtību.) Lai izprastu OOP jēgu ir jāmaina domāšanas veids.

p.s. tā skrobāra lekšāna uz augšu rakstot komentu var reāli izvest no pacietības.

oop isti nevar paradit, kas un kaa un kapec neradot visas sources un daudz nestastot par koncepciju no izstradataja puses. Web'a ta viss strada un gala lietotajam pilnigs pohujs kas tur ir apakashaa :)

noisex, da protams ka po tam lietotājam apakšā kas stāv. Tikpat labi tur apakšā var būt C kodiņš kas ģenerē htmlus. Oki, moš pārāk pārspīlēti, bet tas parāda ideju - produkta kvalitāte nav tikai insektu daudzums, jeb pareizāk mazums bet arī tā pārskatāmība, ātradrbība, spēja to uzturēt utml. Neapšaubu neviena šeit esošā spējas to radīt katram ar saviem līdzeķiem. Katram ir tiesības izvēlēties.

Triviāls piemērs varētu būt:

1. uztaisi abstraktu klasi db, kur ir abstraktas metodes tipa connect, close, query, fetch_row
2. uztaisi klasi mysql_db, kas ekstendo klasi db un metodes aizpili ar reālām funkcijām priekš mysql
3. kodā, kur darbības notiek ar datubāzēm izmanto klasi db un tās metodes, konstruē db kā klasi mysql_db

bonusi var būt šādi:

1. ja izdomā datubāzi migrēt piemēram uz MSSQL, tad tikai jāuzraksta mssql_db klase un jāpamaina db inicializācija (līdzīgu efektu gan var panākt arī bes OOP)
2. ja jāizmanto vairākas db - elementāri mendelson - taisam tik vēl vienu db objektu ...

buu un kur šis piemērs slikti strādās bez OOP, bet ar vienkāršām funkcijām un prastu include()?

bubu: nekad neesu ņēmies apgalvot ka to nevar panākt bez oop - var - tikai kas kuram vieglāk, ērtāk, ātrāk ... tāpat arī jāņem vērā, ka topikā tika prasīts piemērs - ar ko tas nav piemērs? Bet ja strikti un bērnišķīgi, kā pats jautājums, jāatbild, kur tas nestrādās bez oop, tad diezvai izdosies izveidot kādu sakarīgu servletu ar include()...

visu var uztaisīt ar un bez OOP. vajag tikai pēc iespējas taisnāku moduli curve_hands.dll ;) ir lietas, kur OOP reāli palīdz, bet ir lietas, kur OOP ir tas pats kas bumbai rokturis.

artima.com

nesen mācību nolūkā vajadzēja vienu softu taisīt, kā rezultātā izdomāju mocīt uz objektiem. Sanāca man sekojošas klases: sql, kalendārs, lietotājs, persona (atšķirīgas darbības no lietotāja, varbūt varēja taisīt abstraktu un tad mantot, what ever), piezīme (objekts, kurš satur piezīmes kalendāram un vēl tur tā viltīgi tika pielietots), logins (organizee pieejas tiesiibas un ielogoshanaas formu), error (klase, kas satur kljuudu pazinjojumus un padodot kļūdas kodu, tiek veiktas attiecīgas darbības).

Tas bija mans pirmais projektiņš, kur sadūšojos ar OOP parunāties, bet īstenībā labums bija gan no OOP- ja vajadzēja mainīt funkcionalitāti, kad tiek izmantotas funkcijas n vietās, tad objekta iekšpusē to izdarīt bija vieglāk, tb, pie funkcijas izsaukšanas nekas daudz nemainās (vai nemainās nemaz). p.s. beigu beigās tas viss tika samalts oop ar procedurālo, jo apbeidzās laiks, lai mierīgi taisītu :)

Un šeit nav jautājums, ko var ar otru, to nevar ar citu - visu var. Bet, ja ir pareizi objekti (+/-) tad tos var lietot atkārtoti, pārrakstot tikai dažas funkcijas.

p.p.s. sql, lietotājs, kalendārs, logins tika ņemts no iepriekšējiem gara darbiem, kā rezultātā pamainīju tikai dažas funkcijas objekta iekšpusē un ieguvu visu ko man vajadzēja eof

Teiksim, RSS: http://paste.php.lv/1487 Augšā Klases kods (ne manis rakstīts) apakšā source, kas nepieciešama RSS feed ģenerēšanai. Triviāli? Varbūt, bet vismaz izskatās pēc saprātīgas OOP pieejas.

kamēr OO ir tikai veids, kā sakārtot funkcijas //citādāk// (tipa kārtīgāk), vari aizmirst par tā lietošanu - tas tev nav vajadzīgs. Svarīgākās OO priekšrocības manuprāt ir inkapsulācija (no ārpuses nav redzams, kāds kods funkcijā iekšā, bet zināms, ka tas maina objekta stāvokli no x1 uz x2), polimorfisms (tev ir vienalga, kas ir šis konkrētais objekts, galvenais, ka tas atbalsta doto interfeisu) un NEVIS mantošana, kas reāliem objektiem bieži vien sanāk tikpat //dabiska// kā sarkans ir apakšklase krāsai.

to misame: argumentee inkapsulaacijas TIK svariigo noziimi ieksh OOP! Mans viedoklis: Tā kā inkapsulācija ir sava veida galaprodukts, tas noziimee, ka man kaa programeetaajam shiis objekta metodes un parametri ir strikti noteikti. Un ja kaadaa dienaa es izdomaashu mainiit objekta metodi, tas man nebuus pieejams. Un ko tad lai es daru? :)

nee nee sava taisniiba jau ir. piem, ja top liels projekts, i kad citam koderim nav jaalien otra kodera darbaa - vai veeljovairaak, ja objekts iet kaa komerciaals produkts (laacz veeljoprjaam nav publiskojis savu SMPP clasi?), bet PHP k.kaa nea!

OOP. A vot jaa - sakaartotiiba. piemeeram man jau ir iekraajushaas savas biblooteekas. :) tipa. (pie manis pa bargu naudu var iepirkt. ;)) kad k.ko vajag, njemu savu bibloteeku tipa incluudo claas failinj, piesliipee vai atvasina un kaa senie latvieshi teiktu: "zajebis".

Laacz, iesaku izlasīt Code Complete, tur viss ļoti skaidri un sakarīgi aprakstīts. shizo: poliformisms ir svarīgs tāpēc, ka ļauj nodalīt izmanojamās funkcijas, un nepieļauj grābstīšanos no ārpuses tur, kur nevajag. Tas ir tāpat kā pēc iespējas mazāk izmantot globālos mainīgos.

viestards: starp citu, es jautaaju par inkapsulāciju nevis par polimorfismu. Un nevis defeniiciju, bet kaa misame uzsveera - noziimiigumu ieksh OOP.

viestards ;)

shizo: tpu, sajaucu terminus. tekstā jānomaina poliformisms ar inkapsulāciju, vēl miegs acīs. :) Svarīgums IMO izpaužas tādā veidā, ka inkapsulācija palīdz piespiest (sevi un citus) veidot korektāku kodu, kas noved pie vieglāk debugojamas programmas. Visas šīs OOP features it kā palielina izstrādes laiku, taču tai pašā laikā samazina maintenance, vismaz tā tam vajadzētu būt.

shizo: daļēji Tev jau atbildēja viestards. Bet nu vēl arī mani $0.02 par to inkapsulāciju. Gadījumā, kad OOA tiek lietots, lai aprakstītu reālus biznesobjektus un sistēma tiek modelēta tā, ka jebkurā laikam momentā sistēmas objekts atbilst saprātīgam biznesobjektam, parādās liela nozīme inkapsulācijas jēdzienam - objekta publiski pieejamo metožu veidotais interfeiss nodrošina pārejas starp dažādiem loģiski pamatotiem stāvokļiem. Taču, tā kā pieejama arī mantošana, dažādām mantotajām klasēm var pastāvēt dažādas implementācijas vienai un tai pašai pārejai starp dažādiem stāvokļiem - un tad šeit arī ir svarīga inkapsulācija, kas dod iespēju to skaisti realizēt. Par to "vēlāk gribēšu mainīt parametrus" - nesapratu, vai runa ir par interfeisa, vai par implementācijas mainīšanu? Ja doma ir mainīt interfeisu, tad tā ir slikta doma. Vienīgi ko var darīt - likt klāt jaunas metodes ar papildus parametriem, kas izsauks vecās metodes. Ja doma ir par metodes implementācijas maiņu - tad tieši to jau arī inkapsulācija dod, ka tavas komponentes "klientiem" nav jādomā par to, kā izveidots kods metodes iekšpusē! //fui Lācim, jo teksts bija ar visām garumzīmēm, bet man piesējās, ka es tās nelietojot//

Tak web freimworku var uztaisiit lietojot OOP. Tb lietojot interfeisus un abstraktas klases tu vari uzkodeet akuuno webu nekad neredzot nevienu DB un citus layerus. Tad atnaak cic koderis un rejuuzo tavu freimworku "pluginojot" savus objektus kas implementee tavus kreisos interfeisus. Karoche... visi plugini ir ljoti labi OOP piemeeri!

Mļe! Bet tad būtu uzrakstījuši/iemetuši linku uz rakstu gabalu, kur tas saprotami aprakstīts, nevis tie bezgalīgie piemēri ar automašīnām, krāsām un dzīvniekiem. Idejas no tiem var saprast, bet kad runa ir par abstraktām (netaustāmām) lietām, tad kaut kā nedomājas...

mzm: a mož tas nekur nav aprakstīts? varbūt tie, kas beidzot tikuši līdz pielietojamam OOP, ir tik aizņemti, ka vairs manuāļus neraksta? :DDDD