|
|
|
|
 stran: [1] |
pubi
član
št. sporočil: 1342
|
 |
datum: 31.10.2006 | čas: 19:58 |
LP,
a bi hotel kdo na kratko opisat na 2 enakih primerih:
-enega z pač klasičnim php-jem-če se tako izrazim(pač neobjektnim)
-drugega z objektnim
rad bi samo razumel razliko, da nekje začnem še z objekti, saj naj bi bilo z njimi "enostavnejše" in "hitreje" programirati?
lp
PUBI |
Astro
član
št. sporočil: 389
|
|
datum: 01.11.2006 | čas: 05:32 |
Primer OOP:
Najprej ustvarimo nov razred (class):
class pubi
{
function sporocil()
{
$sporocil = '386';
return $sporocil;
}
}
Zdaj želimo uporabit funkcijo 'sporocil' v tem razredu.
$nov_objekt = new pubi;
print $nov_objekt->sporocil();
Ok, zdaj si pač dobil izpis števila sporočil.
Zakaj torej objektno in ne procedurno?
Amm ... ne vem kako bi to razložil najbolj enostavno ampak recimo nekaj takega:
Kot ti index.php?stran=nekaj pomaga pri tem, da ni treba na vseh straneh urediti headerja, tako ti oop logika pomaga pri združevanju funkcij. Nekoliko pohitri zadevo in poveča preglednost ... čeprav sam vztrajam bolj pri procedurnem.
Don't be evil. - Google |
pubi
član
št. sporočil: 1342
|
|
datum: 01.11.2006 | čas: 09:44 |
aha, torej če prav razumem pač narediš eno funkcijo, ki jo potem lahko uporabljaš v vseh skriptah, al kako?
pa kako je to mišljeno:
$blabla -> bla1
.
.
.
.
lp
PUBI |
Astro
član
št. sporočil: 389
|
|
datum: 01.11.2006 | čas: 10:05 |
Ma za funkcijo, ki jo lahko potem povsod uporabljaš, ti ni treba nobenih razredov. Razredi so potem nekako skupek funkcij in vsega kar potrebuješ za neko sekcijo.
Mnja ... ampak to je res na hitro in osnovno. Recimo, da gre za nekako manj kode - večji rezultat. Lahko narediš config.php kjer imaš zapisane spremenljivke, ki se ponavljajo in nato pač povsod inkludaš ta file. Elegantnejši način je pa z razredi, torej oop.
Recimo, da lahko z eno informacijo v enem razredu narediš vse mogoče.
Mah ... res ne vem kako bi raložil ... precej težko. Predlagam, da si prebereš kakšen uvodni tutorial ker šele s prakso potem dojameš prednosti in slabosti.
Edit: Tudi brez razredov ti ne bo nič manjkalo ... samo en logičen framework si sestavi in je čisto kul. Še posebno, ker so razredi v PHPju precej leseni.
sporočilo je spremenil Astro [01.11.2006 ob 10:08]
Don't be evil. - Google |
Astro
član
št. sporočil: 389
|
|
datum: 01.11.2006 | čas: 10:13 |
http://www.tutorialized.com/tutorials/PHP/OOP/1
Tu si malo poglej.
Don't be evil. - Google |
XpM
član
št. sporočil: 398
|
|
datum: 01.11.2006 | čas: 10:21 |
Citiram:
" LP,
a bi hotel kdo na kratko opisat na 2 enakih primerih:
-enega z pač klasičnim php-jem-če se tako izrazim(pač neobjektnim)
-drugega z objektnim
rad bi samo razumel razliko, da nekje začnem še z objekti, saj naj bi bilo z njimi "enostavnejše" in "hitreje" programirati?
lp
PUBI "
Citiram:
"
Zakaj torej objektno in ne procedurno?
"
Čeravno bo zvenelo pikolovsko si bom vseeno dovolil manjši popravek. Po mojih informacijah se "klasični" princip imenuje "proceduralni" in ne "procedurni" :)
Citiram:
"
Kot ti index.php?stran=nekaj pomaga pri tem, da ni treba na vseh straneh urediti headerja, tako ti oop logika pomaga pri združevanju funkcij. Nekoliko pohitri zadevo in poveča preglednost ... čeprav sam vztrajam bolj pri procedurnem.
"
Na nek način se strinjam s tabo.
Pubi:
Osnovna poanta objektno orientiranega programiranja je, da je koda zlahka prenosljiva - tako jo lahko brez težav uporabiš na več projektih, načelo OOP kode je, da se le-ta ne ponavlja - dobra koda naj ne bi poznala CTRL C, CTRL V, nadalje je OOP koda najprimernejša za velike projekte, ker izboljšuje preglednost, delčki kode so namreč "strogo" ločeni v razredih (class), posamezna funkcija pa je uporabljena večkrat in klicana iz različnih delov skripte!
Citiram:
"
aha, torej če prav razumem pač narediš eno funkcijo, ki jo potem lahko uporabljaš v vseh skriptah, al kako?
"
Tako nekako.
Citiram:
"
pa kako je to mišljeno:
$blabla -> bla1
.
.
.
.
"
$nov_objekt = new pubi;
$blabla -> bla1
$blabla je poljubno ime spremenljivke
-> je operator dostopa - omogoča dostop ali spreminjanje lastnosti predmeta.
new je rezervirana beseda za kreiranje novega predmeta - new moraš uporabiti! ($blabla -> new bla1)
V splošnem je Astro pozabil omenit še, da se lahko znotraj razreda povežeš z razredno funkcijo z $this->ImeFunkcije
v razred lahko dodaš tudi "razredne spremenljivke", primer:
class pubi
{
var $spremenljivka; // var velja za php4, pa php5 uporabi public, protected, private
function sporocil()
{
$xy = $this->spremenljivka;
$sporocil = '386';
return $sporocil;
}
}
sporočilo je spremenil XpM [01.11.2006 ob 10:26]
|
Astro
član
št. sporočil: 389
|
|
datum: 01.11.2006 | čas: 10:35 |
Citiram:
"Čeravno bo zvenelo pikolovsko si bom vseeno dovolil manjši popravek. Po mojih informacijah se "klasični" princip imenuje "proceduralni" in ne "procedurni" :)"
Ok, no ... 
Don't be evil. - Google |
matjaz
član
št. sporočil: 1139
|
|
datum: 01.11.2006 | čas: 10:51 |
http://www.bandrej.com/?url=forum/objave&forumid=12&topicid=250
|
Alkimisticus
član
št. sporočil: 61
|
|
datum: 01.11.2006 | čas: 11:47 |
Objektno programiranje se je razvilo iz proceduralnega, vse kar napišeš objektno lahko napišeš tudi proceduralno, velja tudi obratno !
Zagotovo že vse to veste. Torej zakaj objektno ?
Ime OOP pomeni Object Oriented Programing, razlika je torej v načinu razmišlanja in seveda programiranja.
Pri objektnem programiranju je cilj da čimveč stvari ki se ponavljajo, damo v objekte (hirarhično) zato da se znebimo pisanja ali kopiranja eno in istih funkcij, seveda lahko to naredimo tudi v strukturnem (knjižnice), vendar nam objekti ponujajo hirarhijo/dedovanje, ki ga strukturno programiranje v osnovi nima.Lahko ga seveda sami napisemo.
Hirarhija/Dedovanje : (Oče-sin; enosmerna)
- Klasična : Sin podeduje očetove metode(funkcije).
- Abstraktna : Mešano med Klasično in Pogodbo; Oče da nekaj metod za dedovanje nekaj pa jih zahteva, da jih sin ima
- Pogodba (Interface) : Oče samo pove katere metode more sin imeti, sin ne podeduje ničesar.
Obstaja tudi dvosmerna hirarhija/dedovanje v C++, vendar bistveno bolj zakomplicira stvar. Seveda je še veliko drugih stvari.
In zakaj je dedovanje tako dobro ?
Ker nam omogoča da naredimo framework/ogrodje, ki je primerno za veliko stvari (bolj obširno kot knjižnice).
Olajša tudi programiranje, saj nam ni toliko treba skrbeti za osnovne stvari in se lahko bolj osredotočimo na projekt.
OOP je primeren predvsem za velike projekte, da lahko vzdržuješ red. Brez OOP bi bilo skrajno naporno programirat vse desktop aplikacije, da o igrah ne govorimo.
Slabe lastnosti OOP:
- Hitrost (Ker je vse bolj ohlapno, je seveda več kode, ki je sicer ne vidiš zaradi hirarhije)
- Težje za naučit (naravni primer: Od moje tete moža sin se je poročil z od mojga prijatla setrične mame brata hčerko)
- Spoštovanje hirarhije (frameworki so fajni, sam moraš delat tako kot si so oni zamislali)
- Načrtovanje na začetku (Veliko težje se kr spustiš v projekt in napišeš nekaj in potem po potrebi spreminjaš, če želiš imeti pravi OOP moraš takoj poskrbet za osnovno strukturo, drugače je vseeno če kr strukturno programiraš)
Upam da vam je to kaj pomagal.
LP, Alkimisticus (Java programer, prej C)
Izkušen web programer |
MrM
član
št. sporočil: 2078
|
|
datum: 01.11.2006 | čas: 13:31 |
Alkimisticus se je še najbolj približal pravi razlagi. Objektno usmerjeno programiranje (OOP) vsekakor ne pomeni samo uporabljanje classov namesto funkcij, ampak popolnoma drugačen koncept gledanja na aplikacijo. Koncept objektnega programiranja je prej bolj "naraven" kot manj naraven, je pa res, da ni zelo preprosto "preklopiti", če pred tem že dolgo programiraš proceduralno. Mislim, da za pravo razumevanje objektnega programiranja ne bo dovolj, da si prebereš le kakšen "quick start tutorial", ampak je priporočljivo, da vzameš v roke kakšno konkretno knjigo na to temo.
Ko boš dojel osnovno logiko objektnega programiranja, pa si preberi še o:
- enkapsulaciji
- dedovanju
- polimorfizmu
- modularnosti
- SoC
- design patterns (npr. Gang of Four: Design Patterns)
- MVC
- ...
Priporočam tudi knjigo PHP 5 Objects, Patterns, and Practice, vendar si prej poglej vsaj osnove objektnega programiranja.
Mogoče se na prvi pogled zdi vse skupaj preveč komplicirano, vendar verjemi, da si boš hvaležen, če se boš malo bolj poglobil v OOP.
God is real, unless declared integer. |
CWIZO
član
št. sporočil: 3291
|
|
datum: 01.11.2006 | čas: 14:27 |
še tole bi dodal k MrMjevem postu: pa še prehod na ASP.NET ali pa JSP ali kaj podobnega bo lažji.
.:3delavnica.com:.
Another day, another bug |
fatg
član
št. sporočil: 1693
|
|
datum: 01.11.2006 | čas: 16:22 |
Alkimisticus:
Citiram:
"- Hitrost (Ker je vse bolj ohlapno, je seveda več kode, ki je sicer ne vidiš zaradi hirarhije)
- Težje za naučit (naravni primer: Od moje tete moža sin se je poročil z od mojga prijatla setrične mame brata hčerko)
- Spoštovanje hirarhije (frameworki so fajni, sam moraš delat tako kot si so oni zamislali)
- Načrtovanje na začetku (Veliko težje se kr spustiš v projekt in napišeš nekaj in potem po potrebi spreminjaš, če želiš imeti pravi OOP moraš takoj poskrbet za osnovno strukturo, drugače je vseeno če kr strukturno programiraš)"
1) hitrost je vedno podobna, razlike so marginalne. Poleg tega je irelevantna za primerjavo, ker je zanemarljiva v primerjavi s kakršnokoli operacijo. Kaj ti pomaga 1ns, če s poizvedbo na bazo izgubiš 100ms? Prav tako je razlika v hitrostih odvisna od jezika, v katerem primerjaš. Tega "argumenta" se zaradi teh razlogov nikoli ne navaja v taki primerjavi.
2) Nekateri pravijo, da je OOP lažji za naučit, samo proceduralnega programiranja ne smeš prej znat. Zdi se mi hecno, ampak možno. Proceduralno programiranje namreč vsili en tak način razmišljanja, da so podatki ključni in da je vse dostopno, ki ga OOP potem razbija. Žal tega ne morem sprobati, se javi kdo, ki sploh nič ne zna? :)
3) Hierarhija = slab argument. Frameworki ti v zameno dajo nekaj, kar bi drugače moral spisat sam -- potem bi pa extendal svoje osnovne razrede in bi bil spet fiksiran. Temu se ne moreš izogniti v OOP, ker ni slabost, ampak prednost in namen -- če objekt je nekega tipa, potem naj deduje. Za dodaten nivo abstraktnosti imaš pa interface, ki poskrbi, da si lahko "doma" v drugem drevesu.
4) Načrtovanje je gora znanja zase, ki pa ti je sploh ni treba znati, če razvijaš s testiranjem. Tudi če ne, obstaja star programerski pregovor, da je overdesigning slabši od no-designinga.
lp :)
you\'re never too fat to do it |
Alkimisticus
član
št. sporočil: 61
|
|
datum: 01.11.2006 | čas: 18:38 |
1. Hitrost
Mislil sem na teoretično hitrost (število ukazov, velikost potrebnega pomnilnika). OOP je sistem programiranja, ki žrtvuje hitrost in spomin na račun preglednosti,modularnosti,lažjega vzdrževanja,nadgradljivosti itd. Če primerjaš dva programa ki opravljata isto funkcijo, eden je napisan kot OOP drugi pa klasično. Bo program napisan klasično vedno hitrejši, če bi imela isto hitrost bi bila enaka.
2. Težje za učit
OOP je koncept, ki ga brez predhodnjega znanja programiranja težko osvojiš, razen mogoče če ne pišeš kode ampak samo vizualno sestavljaš objekte (UML). OOP nič ne razbija ramišljanja strukturnega programiranja, samo nadgrajuje. Tako kot programiranje v C nadgrajuje programiranje v Asemmblerju. V C imaš int,char,long v Aseemblerju imaš registre. Vsak nivo doda novo kompleksnost in s tem nove možnosti.
Programerji, ki programirajo strukturno, mogoče težko razumejo ker uporabljajo objekte vsak dan kot na primer: tip String, ki je objekt ki ovije charater array in mu doda dodatne funkcije/metode, skrbi da je lahko string poljubno dolg itd. String sicer ne uporablja hirarhije in je osnovni del programskih jezikov pa vendar je objekt kot vsak drug.
Ko pa sami želijo narediti objekt pa se začnejo problemi, ker je to nekaj čisto novega. Sam v osnovi je objekt isto kot primarni tip(primer : int), ti ga lahko napolniš z vrednostmi in napišeš funkcije/metode da te vrednosti vrnejo,nastavijo ali spremenijo. Tipu int na primer lahko napolniš z vrednostjo jo prepišeš, če bi pa na primer želel vedeti koliko števil je v tipu int pa bi naredil objekt ki vsebuje int in funkcije/metode ki vrnejo število številk v int.
Seveda sta int in string za uporabo precej drugačna od objektov, ker sta optimizirana za programiranje in jih kompiler/interpreter pozna. Vsi ostali objekti ki pa jih sami definiramo pa sledijo OOP načelom, ki jih določa jezik.
3. Hirarhija
Sem napisal da so frameworki super reč. Vendar je podobno kot z avti, ne more bi noro hiter, družinski in terenc hkrati. Slabost je v tem da frameworki ne rešijujo enega problema kot funkcije v knjižnicah ampak te silijo da se ti podrediš njim, če jih želiš uporabljat.
4. Načrtovanje na začetku
Vsak ki programira testira, drugače sploh ne ve če program dela tako kot bi moral. Razlika je samo koliko časa temu posveti. Načelo bolj je enostavno boljše je sicer lepo programersko načelo, vendar vzame več časa. Kdor nima v glavi ma pa v petah/prstih.
OOP je namenjen predvsem za velike projekte zato je tudi načrtovanja malo več. Primer: Za lopo ne rabite veliko načrtovanja za stolpnico/hišo pa kar nekaj.
LP, upam da bo za kej .. :)
Izkušen web programer |
fatg
član
št. sporočil: 1693
|
|
datum: 01.11.2006 | čas: 23:45 |
1) Se ne strinjam - vse je odvisno od primera. Najbolj preprost proti-primer: pri proceduralnem programiranju dostikrat prenašaš večje bloke podatkov kot argumente za funkcije, kar stvar upočasni bolj, kot katerikoli objektni konstrukt. Torej, če moraš spisati dva programa, enega strukturno, drugega v OOP, potem je dostikrat OOP hitrejši. To je zato, ker lahko sestaviš boljšo rešitev, ne zato, ker je klic metode hitrejši od klica funkcije. Kaj potem meriš? 1000x klic prazne funkcije proti 1000x klic prazne metode ali čas izvajanja nekega problema v obeh variantah? Če prvo, zmaga strukturno. Jalova zmaga, ne?
2) Se spet ne strinjam. Prehod asm->C je res samo nadgradnja, saj je vendar asm praktično proceduralna koda -- prehod je samo v sintaksi.
Vendar pri prehodu na OOP ni tako, temveč tako, kot sem napisal: OOP razbija proceduralni način razmišljanja. Ne gre za sintaktično nadgradnjo, temveč za novo dimenzijo. Pri proceduralnem programiranju je fokus na podatkih in njihovem prehajanju skoz sistem, pri OOP pa na odgovornosti objektov in njihovem medsebojnem sodelovanju. Podatek nenadoma postane nepomemben, ker je samo stvar končne implementacije. To je preskok, ki ga veliko ljudi, ki prehaja iz proceduralne kode, ne naredi. Taki še naprej pišejo proceduralno kodo, le da je pogrupirana v objekte -- in to ni objektno programiranje.
3) Frameworkov je veliko. Eni te omejujo bolj, drugi manj. Vsak da od sebe samo toliko, kolikor dobro je bil ustvarjen. Na tebi je samo, da izbereš problemu primerno orodje -- najpomembnejša odločitev pri razvoju. Če želiš funkcije v knjižnicah, imaš PEAR. Če želiš dober framework, si poglej Symfony.
4) Mislim, da ne razumeš, za kaj gre pri Unit Testingu. Preberi si članek. XP metodologija celo uči, da je načrtovanje popolnoma odveč -- sistem naj bi skozi TDD sam od sebe razvil pravilno obliko. Če sodim po svojih izkušnjah, reč drži, je pa težko.
you\'re never too fat to do it |
ace
član
št. sporočil: 1291
|
|
datum: 02.11.2006 | čas: 00:29 |
Alkimisticus> za lopo rabiš premo sorazmerno načrtovanja glede na čas gradnje kot za hišo. Se pravi neka subjektivna ocena kdaj je projekt majhen nebi smela biti razlog za povsem drugačen način dela, ker navsezadnje gradiš precej podobno zadevo.
Torej ali delaš vse objektno ali pa ne, kar mislim da je tudi najpogostejša praksa.
Sicer pa kot fatg se tudi jaz nebi strinjal z nobeno od tvojih točk, samo bom malo krajši v razlagah:
1. hitrost: irelevantno majhnje razlike in ne poznam nikogar, ki bi zaradi tega prilagajal način programiranja. Primerljivo se mi zdi, če bi kupil drug avto ker bi prvi rabil 0,5sekunde več pri vžigu.
2. težje za naučit: precej relativno, ker je to samo nadgradnja znanja in nikakor ne moreš z tem začeti učenje. V vsakem primeru pa ni neka višja znanost in za osnovne potreba dokaj doumljiva oseba zadevo pokapira v parih dneh in vse skupaj je potem koristno za celo programersko kariero.
3. framework lahko spišeš tudi svoj baje. (nisem pa siguren, tako da naj nekdo prosim potrdi mojo izjavo)
4. osnovna ideja načrtov je ta da se jih držiš in da ni treba kasneje sklepati kompromisov in generalno spreminjati zadev. Čas ki ga porabiš za načrt pridobiš nazaj pri hitrosti izvedbe. Tudi makete lahko sestavljaš brez da bi gledal načrt in ziher bo šlo hitreje, samo kar boš na koncu sestavil ne bo ravno pravilno in boš porabil ogromno časa da boš popravil.
[url=http://www.mp3.com.au/acecream]KLIK KLIK KLIK KLIK...[/url] |
Alkimisticus
član
št. sporočil: 61
|
|
datum: 02.11.2006 | čas: 11:15 |
Jaz sem povedal svoje mnenje glede OOP programiranja.
Ne trdim da je moje mnenje pravilno, ker imam samo praktične izkušnje in premalo znanja teorije, da bi ga lahko ubranil.
Sam za enkrat še stojim za njim.
Glede novih stvari: Poznam Unit testing in Extreme programing (nič kaj posebnega,včasih pride prav) in framework lahko sam napišeš.
LP Alkimisticus
Izkušen web programer |
fatg
član
št. sporočil: 1693
|
|
datum: 02.11.2006 | čas: 18:46 |
Citiram:
"Jaz sem povedal svoje mnenje glede OOP programiranja.
Ne trdim da je moje mnenje pravilno, ker imam samo praktične izkušnje in premalo znanja teorije, da bi ga lahko ubranil.
Sam za enkrat še stojim za njim."
Na srečo pri teh zadevah ne gre za mnenje, temveč za teorijo, ki je definirana, spisana, razložena -- in včasih tudi prebrana. ;)
Citiram:
"Glede novih stvari: Poznam Unit testing in Extreme programing (nič kaj posebnega,včasih pride prav) in framework lahko sam napišeš."
XP je sicer relativno nova zadeva, Unit testing pa nikakor. In če je XP metodologija razvoja, ki jo lahko izbereš ali pa ne, je nasprotno UT pri razvoju resnih aplikacij nepogrešljiv. Mnenje "nič kaj posebnega, včasih pride prav" pokaže neizkušenost in nerazgledanost.
LP
you\'re never too fat to do it |
|
|
stran: [1] |
|
|
|
stran
je še vedno v izdelavi zato nekatere stvari manjkajo
oz. niso dokončane |
|
|
|
|
| |
|
