Gå til innhold

OOP noe vits i å lære seg?


Anbefalte innlegg

Videoannonse
Annonse

både ja og nei. OOP egner seg veldig godt til større prosjekter der varialer skal overføres gjennom flere funksjoner, du har også mange muligheter i f.eks et include script:

 

switch($_GET['side']){
 case 'main':
    $driver = new main;
    break;
 case gallery:
    $driver = new gallery;
    break;
 default:
    $driver = new main;
}

$driver->display()
}

 

i eksemplet over ser du at du kan dynamisk tilordne en klasse til et objekt med samme navn og kjører en funksjon med samme navn, men som gjør to forskjellige ting. OOP har en støre dynamisk mulighet en vanlig funksjons skriving, så ja. OOP er absolutt å lære seg. "Å gidde å lære seg" er en dårlig holding i dagens værden, du må ville lære ALLT! ;)

Lenke til kommentar

OOP er absolutt verdt det!

Som sagt, til større prosjekter....

Skal du "redigere"/fikse/optimalisere/osv. senere hjelper det veldig, er mye mer ryddig!

Også ressursmessig er OOP en stor fordel.

Med tanke på hvordan pc'en jobber, er OOP raskere enn "vanlig"!

Lenke til kommentar

Ja, jeg programmerer et proskjekt i VB.NET nå.

 

Hvor jeg har flere forms som bruker samme functions, i stede for å samme functions skrevet om igjen i hver av formene. Skrev jeg en .dll som inneholdt alt jeg trengte til formene. Siden kun et form er aktivt om gangen funka dette fett...

Mindre kode, raskere kode :p

Lenke til kommentar
Med tanke på hvordan pc'en jobber, er OOP raskere enn "vanlig"!

5735177[/snapback]

 

Hm... Fortell mer om dette.. :hmm:

5735191[/snapback]

hmm, hvilken versjon skal du ha; den på 10 sider eller 100 sider?

Skal prøve å finne en artikkel om det, så kan du lese....

 

EDIT:

Her er en liten innføring på 38 sider ;)

5735198[/snapback]

 

Joda, jeg vet hvordan en datamaskin fungerer, men jeg var interessert i hvordan objektorientering utnytter dette på enn bedre måte en sekvensiell programmering (det stod det ingenting om på linken).

Edit: Leif

Endret av Paull
Lenke til kommentar

Nei, det sto vel ikke noe om OOP på den linken nei....

Men uansett, en datamaskin jobber abstakt og liker abstrakte ting.

Og som chills sa, mindre kode, raskere kode...

 

Og får å ikke nevne hvordan maskinen hasher data til og fra både cache, ram, hd, etc.. Paging er ganske viktig begrep, ja, kan nevne i fleng!

Innholdet i cpu'en har veldig mye å si slik som addere, datapather, registre, o.l. Deretter kommer assembly og binær- og heksa-kode....

Jaja, får ikke bli ALTFOR off-topic her....

Lenke til kommentar
Med tanke på hvordan pc'en jobber, er OOP raskere enn "vanlig"!

5735177[/snapback]

 

Hm... Fortell mer om dette.. :hmm:

5735191[/snapback]

 

Jeg vet ikke hva Oxido tenkte på, men faktum er jo at det medfører et visst ekstraarbeid for datamaskinen å eksekvere objektorientert programkode. Det tar altså målbart lengre tid å utføre slik kode fremfor en (tilsvarende optimalisert) ikke-objektorientert programkode. Derimot er ikke forskjellen merkbar i de aller, aller fleste tilfellene, og ettersom objektorientert kode er enklere å vedlikeholde, så anbefales selvsagt OOP.

 

Derimot er det en lang tradisjon innen PHP-programmering for å avsky OOP, men det skyldes nok først og fremst PHPs spesielle bruksmønster, samt at PHP før versjon 5 ikke gjør det enkelt for programmereren å velge OOP.

Lenke til kommentar
Skal du "redigere"/fikse/optimalisere/osv. senere hjelper det veldig, er mye mer ryddig!

5735177[/snapback]

Det kan man også med vanlige funksjoner

 

Også ressursmessig er OOP en stor fordel.

Med tanke på hvordan pc'en jobber, er OOP raskere enn "vanlig"!

5735177[/snapback]

NEI! Dette stemmer overhode ikke. OOP er vesentlig tregere enn vanlige funksjoner. Hovedårsaken til dette er at man skal opprette et objekt, men også det å kjøre selve funksjonene går noe treigere.

 

Til vanlig bruk er OOP direkte unødvendig. PHP er overhode ikke et språk man benytter OOP i samme utstrakte grad man gjør i f.eks C++ eller Java. Skal OOP ha noen faktisk nytte bør man lage flere enn 1 objekt av en klasse. Det har jeg hittil til gode å se i PHP ...

 

Bare så det er sagt, det er ingenting du ikke kan få til med funksjoner. Pjattet om at OOP gjør ting mer oversiktelig går jeg ikke på. Det å lage en klasse gjør det ikke koden automatisk mer oversiktelig og lettere å vedlikeholde. Det er bare det at enkelte er såpass trangsynte at de ikke klarer å se at man fint kan klare samme oppgave med bare funksjoner og samtidig ha det minst like oversiktelig og vedlikeholdbar kode.

Endret av Ernie
Lenke til kommentar

Så man kan "resirkulere" en funksjon, altså bruke den mange ganger, uten at den er inni en klasse?

 

Altså er det bare en dum ide å bruke OOP på en 100-200 linjers PHP-fil?

 

Hørte også at ikke alle servere støttet OOP fullt ut enda? Stemmer det?

 

Vil det ikke i praksis, med en liten side, være like greit å ha masse funksjoner framfor å bruke include(fil.php);?

Lenke til kommentar

ja, jeg synes include() script på mindre sider er unødvendig, og du slipper automatisk sikkerhetshullet runt include(). Du kan også bruke en metode omtrent lik mitt første eksempel uten OOP, men med noen innebygde funksjoner i php.

 

Som Ernie sier er ikke PHP hovedsaklig laget for OOP, men det fungerer utmerket. det hele kommer helt ann på hvoirdan DU liker å skrive kode, ikke hva jeg eller Ernie liker.

 

OOP er en smule tregere en vanlig, men her er det snakk om så små tidsforskjeller at de neppe aldri vil være merkbar på en webaplikasjon.

Lenke til kommentar

Jeg liker veldig godt å kode OOP, rett og slett fordi det er en tankegang jeg trives med. Funksjoner knyttes naturlig til objekter, og personlig synes jeg OOP er mer oversiktlig. Det finnes utallige sider som taler for og imot OOP i PHP. PHP er _ikke_ raskere eksekveringen av OO kode, selv om det har blitt bedre i PHP5. Det raskeste er sekvensiell programmering, uten noen brukerdefinerte funksjoner, deretter kommer sekvensiell programmering med brukerdefinerte funksjoner, og OO kode kommer helt til sist. Fordelen med OO kode er måten du kan knyte objekter sammen og bruke kode om igjen på objekter som er knytt sammen. Dette kommer, som Ernie sier, mer tilrette i språk som Java, C++ og C#, da de ofte har litt andre bruksområder (les applikasjoner), men jeg synes fortsatt det å si at sekvensiell er den eneste rette veien i PHP er feil. og jeg oppfordrer alle til å prøve ut begge deler, og finne ut hva de er mest komfortable med. Du burde uansett ha kjennskap til begge deler, da du før eller siden ender opp med å lese andres kode, som kanskje ikke følger dine preferanser.

 

Eksempel på hvor jeg bruker OO i php er for database-klasser, der jeg har en enkel DB klasse, som bruker samme funksjoner for både mysql, postgresql, mssql osv. Uten at jeg trenger å tenke på hvordan disse fungerer eller hvilke funksjoner som må brukes for hver databasetype. F.eks. kan jeg lett gå fra å bruke mysql som er en client->server basert database, til å bruke sqlite som er en flatbasert database, og den eneste endringen jeg må gjøre er å bruke new Sqqlite(...) istedet for new Mysql(...). Funksjonskallene som brukes er de samme gjennom klassen min, så da trenger jeg ikke gjøre noen andre endringer i koden min.

 

En annen ting man burde tenke over er hvorfor de som lager PHP bryr seg så mye om å implementere OOP, dersom det ikke skal ha noen fordeler.

Endret av Nazgul
Lenke til kommentar

Alt for sin plass mener jeg. OOP er en måte som kan til tider være nyttig i PHP, men etter min mening bør holdes enten borte eller til et minimum. OO er tregere (markant) enn sekvensiell, og for en webapplikasjon betyr hastighet mye. I C++ og Java snakker vi om et helt annet felt, og helt andre størrelser på struktur, samt bruksområde da disse er OO. I det tilfellet vil også brukeren av et slikt program være mer støttet av hatighet til maskin og eget utstyr, mens brukeren av en webapplikasjon skal dele resurser med andre.

 

OO i PHP5 HAR blitt bedre, men det er enda ikke godt nok for at det er legimitert å bruke aktivt.

 

Så en kan godt lære seg OOP, men for all del vil jeg sterkt fraråde å bruke dette med mindre til der det er en klar fordel (som f.eks mot database). Det er viktig å se nytten av koden før en pumper på med OO. Spør deg alltid først "Kan jeg gjøre det samme uten OOP"?

Endret av allyse
Lenke til kommentar

Da blir det litt bortrensking av OO i koden min da. Liker ikke å måtte bruke $this->variabel

når jeg kunne nøyd meg med $variabel

og så må man definere et objekt også før man bruker en funksjon .. så for små sider (hvertfall) må det da være enklere med bare funksjoner.... (greit å kunne kalle opp "logg på databasen" flere steder)

Lenke til kommentar

Vil du en dag ha jobb som utvikler så MÅ du lære deg OOP, og da hvorfor ikke i php. Ikke kom her og fortell meg at noen her sitter og lager superscripts på sider med milioner av besøkende og selger for millioner, og derfor MÅ progge for hastighet. Så argumentet om hastighet er misvisende siden ingen her trenger det.

 

All regel om optimalisering er at det er noe man gjør når man har programmert noe ferdig. DA kan man se om det er nødvendig å optimalisere koden. Så den hastighetsdiskusjonen kan man kaste på sjøen.

 

Rask, optimalisert kode er ofte uleselig, kryptisk, og MEGET tilpasset nøyaktig det den skal gjøre og lite egnet til gjenbruk. Derfor så er det uønskelig å programmere alt på en slik måte.

 

Skal man planlegge hvordan man skal lage en applikasjon så er OOP den beste måten å visualisere kode, ansvarsområder, hvem skal gjøre hva, struktur osv. Hvis hver person programerer hver for seg så øker faren for problemer, sikkerhetshull, dobbeltarbeid, ustruktur, sløsing av penger osv osv med logaritmiske proposjoner.

 

Man kan jo unngå OOP men samtidig ha noe struktur, med å legge ting ut i en bråte funksjoner ... men da blir jo spørsmålet om hvorfor man da ikke oppretter klasser? så mye overhead kan det umulig være.

 

Ser man på PEAR biblioteket så er den jo gjennomsyret med OOP, og dette er et populært bibliotek. Var hastighet så dårlig på OOP kode så ville jo ikke PEAR folka brukt OOP. Samme ser man på forsøket fra Zend som lager et generellt bibliotek for PHP .. også i OOP.

 

Myten om at kun kode som benyttes "om igjenn" skal legges ut i funksjoner, og objekter man bruker "om igjenn" kan skilles ut blir veldig snevert.

Helt ok er det viss man programmerer alene. Men samarbeider man om å lage web-sider så er det misbruk av tid. Det finnes for mange "ok" programmerer som gjør mye feil, og gå over all kode for å finne feil hos den enkelte tar mye tid. Finner man plutselig ut at man må validere en eller annen input, så er det bedre å vite hvilken klasse det er som håndterer denne inputen og løse problemet på en spesifikk plass, enn å gå over 40 web-sider som gjør rare database kall direkte.

 

PHP brukes idag svært lite i kommersiell sammenheng sammenligner man med java og asp. PHP er dårlig på OOP, og er definitivt en av grunnene til at utviklingsfirmaer skyr PHP, sammen med potensielle patentproblemer som har en lei tendens å følge open source applikasjoner.

 

PHP er et språk for de som utvikler web-sider på gutterommet, de som er nerder eller open source fundamentalister. PHP begynte jo tross alt som et ANTI-OOP språk og ble holdt slik veldig lenge.

 

Kan man ikke OOP så er det definitivt noe man må lære seg, med mindre man kun ønsker å være nerd og aldri ta en ordentlig programmeringsjobb.

Lenke til kommentar
Vil du en dag ha jobb som utvikler så MÅ du lære deg OOP, og da hvorfor ikke i php.

5747227[/snapback]

Fordi det er et slapt latmannsspråk som ikke lærer deg stort annet enn å lage php-script. Noen god innføring i programmeringstankegangen gir PHP iallfall ikke. Jeg hadde selv bare bakgrunn fra PHP når jeg lærte meg C++, og den eneste fordelen jeg hadde var at jeg viste hva en for, while og do-løkke er samt også hva if/elseif/else er.

 

Rask, optimalisert kode er ofte uleselig, kryptisk, og MEGET tilpasset nøyaktig det den skal gjøre og lite egnet til gjenbruk. Derfor så er det uønskelig å programmere alt på en slik måte.

5747227[/snapback]

Rask og optimalisert kode er så uleslig eller uleslig man selv vil ha det. Selv klarer jeg fint å få det leslig. Ikke-triviell kode vil uannsett være vanskelig for de fleste å skjønne.

 

Skal man planlegge hvordan man skal lage en applikasjon så er OOP den beste måten å visualisere kode, ansvarsområder, hvem skal gjøre hva, struktur osv. Hvis hver person programerer hver for seg så øker faren for problemer, sikkerhetshull, dobbeltarbeid, ustruktur, sløsing av penger osv osv med logaritmiske proposjoner.

5747227[/snapback]

Det går fint an å planlegge en applikasjon uten OOP. OOP er heller ingen garanti mot problemene du nevner ...

 

Man kan jo unngå OOP men samtidig ha noe struktur, med å legge ting ut i en bråte funksjoner ... men da blir jo spørsmålet om hvorfor man da ikke oppretter klasser? så mye overhead kan det umulig være.

5747227[/snapback]

Hvis du bare har funksjoner så er det direkte stygt å lage en klasse ut av det, slikt får du til informasjon et saftig trekk for på en innlevering på høgskole.

 

Ser man på PEAR biblioteket så er den jo gjennomsyret med OOP, og dette er et populært bibliotek. Var hastighet så dårlig på OOP kode så ville jo ikke PEAR folka brukt OOP. Samme ser man på forsøket fra Zend som lager et generellt bibliotek for PHP .. også i OOP.

5747227[/snapback]

Nå ville jeg da ikke sånn umiddelbart brukt noe fra PEAR i en større løsning. OOP er dømt til å være treigere enn procedural enten du vil det eller ei.

 

Myten om at kun kode som benyttes "om igjenn" skal legges ut i funksjoner, og objekter man bruker "om igjenn" kan skilles ut blir veldig snevert.

Helt ok er det viss man programmerer alene. Men samarbeider man om å lage web-sider så er det misbruk av tid. Det finnes for mange "ok" programmerer som gjør mye feil, og gå over all kode for å finne feil hos den enkelte tar mye tid. Finner man plutselig ut at man må validere en eller annen input, så er det bedre å vite hvilken klasse det er som håndterer denne inputen og løse problemet på en spesifikk plass, enn å gå over 40 web-sider som gjør rare database kall direkte.

5747227[/snapback]

Om man virkelig koder slikt seriellt så hadde jeg kuttet det ut. Funksjoner er et must samma faen, og disse må spres over flere filer. Om man da presterer å ikke klare å finne igjen funksjonen de gjelder så har man lite med profesjonell programmering å gjøre ...

 

PHP brukes idag svært lite i kommersiell sammenheng sammenligner man med java og asp. PHP er dårlig på OOP, og er definitivt en av grunnene til at utviklingsfirmaer skyr PHP, sammen med potensielle patentproblemer som har en lei tendens å følge open source applikasjoner.

5747227[/snapback]

Asp foretrekkes primært fordi man kjører Windows og ikke fordi PHP har elendig OOP-muligheter. Open source har forøvrig knekkelig lite med PHP å gjøre. Går fint an å "kryptere" filene slik at ikke en levende sjel skjønner noe av det der med det første.

 

Kan man ikke OOP så er det definitivt noe man må lære seg, med mindre man kun ønsker å være nerd og aldri ta en ordentlig programmeringsjobb.

5747227[/snapback]

Selvsagt, OOP har sine fordeler, men sitt nå ikke naivt og tro på myten om at OOP funker over alt. Skal man bruke OOP så bør det være en god begrunnelse for det, ikke at det gjør koden enklere og raskere å produsere eller at det gjør koden mer oversiktelig, for det er myter som ikke holder mye vann.

 

OOP er kjekt, men ikke når du bare lager et objekt av det. Da er du på blåbærtur.

 

Edit: En rekke endringer for å understreke litt ekstra hva jeg mener.

Endret av Ernie
Lenke til kommentar

Jeg hadde erfaring fra VB når jeg først tok opp C++ for alvor. Og må innrømme at mye av det du koder går igjen, så viss du jobber grundig og kommenterer koden din vil du kunne bruke igjen mye av det i fremtidig applikasjoner.

 

Men for all del, små programmer og mindre prosjekter trenger du ikke og skrive et .lib. Men viss flere forms skal bruke samme funksjoner er det vel like greit og lage et lib og la de dele koden.

 

Jeg har dog ingen erfaring fra PHP, webutvikling tar jeg i ASP.

 

Svein. :)

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...