trenger litt kritikk til noen klasser

[phun-ky]

lurte på om jeg kunne fått litt kritikk på klassene jeg har laget til en applikasjon, om evt forbedringer og syntaks feil som jeg evt. har. klassene fungerer, men om de kunne blitt skrevet bedre (php4)

 

http://www.umedia.no/code/bin/functions.phps

 

på forhånd takk!

[allyse]

Har ikke så mye input til klassen, men hvorfor i alle dager bruke klasse til dette? Det vil resultere i en ting: Tregere script, og mindre proff look...

[phun-ky]

stiller meg veldig tvilende til din konklusjon der..

[King Saul]

Klasser er jo som regel bedre - siden du kan lage flere "instances" av en klasse. Også det at du behandler klassen og ikke noe intetbefinnende....

 

Klasser er derimot bullshit til små funksjoner.

[Ernie]

stiller meg veldig tvilende til din konklusjon der..

5587536[/snapback]

Klasser er solid treigere enn rene funksjoner i PHP4.

[allyse]

stiller meg veldig tvilende til din konklusjon der..

5587536[/snapback]

 

Klasser (spes i php4) er trege. Når du skal gjøre noe så enkelt som billedbehandling er det greiest å ikke bruke klasser da du skal bare kjøre et sett kommandoer uansett. Men om du tviler på hva jeg sier så kan du heller si (begrunne) hvorfor du vil bruke klasser? Kunne godt få sett noen timere på scriptet ditt med og uten klasse

[Ueland]

Å ha en klasse for EN funksjon høres for meg heller veldig rart ut, når du starter klassen kjøres jo funksjonen, så hvorfor ikke hoppe over det ene leddet da?

 

Hadde den ene klassen gjort mye så hadde det selvsagt vært en annen sak, men EN funksjon er og blir overkill.

 

Men forøvrig må jeg få si at kodedokumentasjonen var bra

[jorgis]

Har ikke så mye input til klassen, men hvorfor i alle dager bruke klasse til dette? Det vil resultere i en ting: Tregere script, og mindre proff look...

5587424[/snapback]

 

Hva har "look" med koding å gjøre? Greit nok, en elegant løsning på et programmeringsproblem er tøft og i mine øyne ren kunst, men å endre kodestil (spesielt å gå fra OOP til prosedyrell programmering) på grunn av "look" er bare idiotisk.

[allyse]

Har ikke så mye input til klassen, men hvorfor i alle dager bruke klasse til dette? Det vil resultere i en ting: Tregere script, og mindre proff look...

5587424[/snapback]

 

Hva har "look" med koding å gjøre? Greit nok, en elegant løsning på et programmeringsproblem er tøft og i mine øyne ren kunst, men å endre kodestil (spesielt å gå fra OOP til prosedyrell programmering) på grunn av "look" er bare idiotisk.

5594724[/snapback]

 

Poenget er ikke hva som er "look" i dens formening. Det er at OOP + php4 er ikke den beste kombinasjonen (hastighet). Å bruke oop til alt i php er ikke profft, og ergo gir en mindre proff look.

[jorgis]

Har ikke så mye input til klassen, men hvorfor i alle dager bruke klasse til dette? Det vil resultere i en ting: Tregere script, og mindre proff look...

5587424[/snapback]

 

Hva har "look" med koding å gjøre? Greit nok, en elegant løsning på et programmeringsproblem er tøft og i mine øyne ren kunst, men å endre kodestil (spesielt å gå fra OOP til prosedyrell programmering) på grunn av "look" er bare idiotisk.

5594724[/snapback]

 

Poenget er ikke hva som er "look" i dens formening. Det er at OOP + php4 er ikke den beste kombinasjonen (hastighet). Å bruke oop til alt i php er ikke profft, og ergo gir en mindre proff look.

5594762[/snapback]

 

Man programmerer ikke et program for at programmet skal ha en fin "look" og se bra ut, men for at det skal fungere så bra som overhodet mulig og dermed også så raskt som overhodet mulig. Om du bruker unødvendig OOP i PHP4 gjør du ikke jobben din skikkelig, og programmet blir ikke så raskt som det kan bli, men at det har en dårlig "look" vil jeg ikke si.

[allyse]

Har ikke så mye input til klassen, men hvorfor i alle dager bruke klasse til dette? Det vil resultere i en ting: Tregere script, og mindre proff look...

5587424[/snapback]

 

Hva har "look" med koding å gjøre? Greit nok, en elegant løsning på et programmeringsproblem er tøft og i mine øyne ren kunst, men å endre kodestil (spesielt å gå fra OOP til prosedyrell programmering) på grunn av "look" er bare idiotisk.

5594724[/snapback]

 

Poenget er ikke hva som er "look" i dens formening. Det er at OOP + php4 er ikke den beste kombinasjonen (hastighet). Å bruke oop til alt i php er ikke profft, og ergo gir en mindre proff look.

5594762[/snapback]

 

 

 

Man programmerer ikke et program for at programmet skal ha en fin "look" og se bra ut, men for at det skal fungere så bra som overhodet mulig og dermed også så raskt som overhodet mulig. Om du bruker unødvendig OOP i PHP4 gjør du ikke jobben din skikkelig, og programmet blir ikke så raskt som det kan bli, men at det har en dårlig "look" vil jeg ikke si.

5594818[/snapback]

 

 

Bruker du feil kode på feil plasser er det uprofft, og det laget selvfølgelig en uproff look. Altså PHP er IKKE er objektorientert programmeringsspråk og da bruker vi OOP på færrest mulig plasser for å holde ytelse og å kjøre en standardlinje.

[jorgis]

Har ikke så mye input til klassen, men hvorfor i alle dager bruke klasse til dette? Det vil resultere i en ting: Tregere script, og mindre proff look...

5587424[/snapback]

 

Hva har "look" med koding å gjøre? Greit nok, en elegant løsning på et programmeringsproblem er tøft og i mine øyne ren kunst, men å endre kodestil (spesielt å gå fra OOP til prosedyrell programmering) på grunn av "look" er bare idiotisk.

5594724[/snapback]

 

Poenget er ikke hva som er "look" i dens formening. Det er at OOP + php4 er ikke den beste kombinasjonen (hastighet). Å bruke oop til alt i php er ikke profft, og ergo gir en mindre proff look.

5594762[/snapback]

 

 

 

Man programmerer ikke et program for at programmet skal ha en fin "look" og se bra ut, men for at det skal fungere så bra som overhodet mulig og dermed også så raskt som overhodet mulig. Om du bruker unødvendig OOP i PHP4 gjør du ikke jobben din skikkelig, og programmet blir ikke så raskt som det kan bli, men at det har en dårlig "look" vil jeg ikke si.

5594818[/snapback]

 

 

Bruker du feil kode på feil plasser er det uprofft, og det laget selvfølgelig en uproff look. Altså PHP er IKKE er objektorientert programmeringsspråk og da bruker vi OOP på færrest mulig plasser for å holde ytelse og å kjøre en standardlinje.

5594860[/snapback]

 

Så slutt å blande look inn i bildet, da! Look har med utseende og stil å gjøre, ikke med om det er god eller dårlig kode!

 

Og jeg vil forresten protestere ganske sterkt mot at PHP ikke er et objektorientert språk. Kanskje PHP4 ikke er det, men PHP5 er det, og PHP6 vil i hvert fall være det.

[allyse]

Så zend tar helt feil når OOP faktisk står på lista over de 21 største programmeringstabbene, og faktisk står det der svart på hvitt php ikke er objektorientert.

 

Jeg kan blande look så mye jeg vil inn i dette. Dårlig programmering lager et dårlig look av koden, og da kan jeg fint bruke det ordet. Tror du skal lese litt mer og kverulere litt mindre jeg.

 

Prøv å presentere OOP-php i jobblivet du om ledelsen veit hva de vil ha. Gled deg til mange timers omskrivning

 

Syntes du skal lese litt på denne siden jeg: http://www.zend.com/zend/art/mistake1.php?...iew=1#Heading13

[Ernie]

 

Så slutt å blande look inn i bildet, da! Look har med utseende og stil å gjøre, ikke med om det er god eller dårlig kode!

 

Og jeg vil forresten protestere ganske sterkt mot at PHP ikke er et objektorientert språk. Kanskje PHP4 ikke er det, men PHP5 er det, og PHP6 vil i hvert fall være det.

5594932[/snapback]

Å kalle PHP for et OOP-språk er å overdrive kraftig. Den lille OOP-lignende funksjonaliteten man har i PHP4 er direkte søppel og noe jeg sterkt fraråder enhver person å benytte. OOP-lignende funksjonalitet i PHP5 fungerer til nød ok, men langt fra noe man bør benytte seg av. Bruken av klasser i PHP er direkte overdrevet pr. dags dato. Klasser i PHP er ikke noe man bør bruke i like stor grad som i ekte OOP-språk som C++ og Java.

 

2 svært typiske trekk på feilbruk:

1. Det lages bare et objekt av klassen

2. Klassen inneholder bare variabler eller bare funksjoner

[jorgis]

Så zend tar helt feil når OOP faktisk står på lista over de 21 største programmeringstabbene, og faktisk står det der svart på hvitt php ikke er objektorientert.

 

Jeg kan blande look så mye jeg vil inn i dette. Dårlig programmering lager et dårlig look av koden, og da kan jeg fint bruke det ordet. Tror du skal lese litt mer og kverulere litt mindre jeg.

 

Prøv å presentere OOP-php i jobblivet du om ledelsen veit hva de vil ha. Gled deg til mange timers omskrivning

 

Syntes du skal lese litt på denne siden jeg: http://www.zend.com/zend/art/mistake1.php?...iew=1#Heading13

5594980[/snapback]

 

Nei, derimot har Zend har helt rett når de sier at en annen manns artikler på deres side ikke sier noenting om deres meninger, og de har helt rett når de sier at artikkelen er kjempegammel og utdatert på akkurat det området. Synes du skal lese litt mer og kverulere mindre, jeg (spesielt er det greit å lese når artikkelen ble publisert ).

 

Zend står ikke bak synspunktet til artiklene på zend.com, og det er heller ingen overraskelse at Sterling Hughes ikke liker OOP; programmerere som kommer fra en C-bakgrunn er skjeldent det. Ellers hadde det virket litt selvmotigende om Zend kom med en offisiell uttalelse hvor de sa at PHP ikke er et OOP-språk, mens de senere slipper PHP5, som er mer OOP en noensinne...

 

Denne artikkelen er skrevet for over fem (snart seks) år siden. I år 2000 eksisterte ikke PHP5 (den første betaen kom i slutten av 2003), og PHP4 er som kjent veldig dårlig til OOP-bisniss. PHP5 har mye bedre støtte for OOP enn PHP4, og har ikke lenger så store forskjeller i fart og effektivitet.

 

Dessuten er det enormt store muligheter som ligger i OOP, bare språket man skriver har støtte for dem. PHP4 hadde ikke det, men med PHP5 kom mange muligheter som man ikke med letthet kan få til uten OOP.

 

EDIT: Men er ikke vi veldig Off topic her nå? Vi skulle vel egentlig gi litt kritikk til klassene trådstarter skrev?

Endret 12. februar 2006 av jorgis

[allyse]

Når det ligger på zend sine sider forventes det en generell kvalitetssikring av innholdet. At han kommer fra C betyr jo bare at han veit hvordan det er å ikke fronte mot OOP.

 

Når det er sagt så snakker vi faktisk om PHP4 her. Hele tråden baserer seg i PHP4. PHP4 har aldri og kommer aldri til å bli Objektorientert. PHP5 inneholder en forbedret støtte, men enda er ikke PHP5 et objektorientert språk. OOP er enda _tregere_ i PHP5 enn ikke-OOP-kode, og det sier vel sitt.

[jorgis]

Når det er sagt så snakker vi faktisk om PHP4 her. Hele tråden baserer seg i PHP4. PHP4 har aldri og kommer aldri til å bli Objektorientert. PHP5 inneholder en forbedret støtte, men enda er ikke PHP5 et objektorientert språk. OOP er enda _tregere_ i PHP5 enn ikke-OOP-kode, og det sier vel sitt.

5595136[/snapback]

 

Hva er da problemet? Jeg har da aldri sagt at PHP4 er et objektorientert språk. Derimot har jeg sagt at PHP5 er mye bedre, og at det å forkaste OOP kun på grunn av at PHP er litt svak på den fronten er tåpelig. Og ja, OOP er og vil alltid være tregere enn prosedyrell kode, rett og slett fordi det er mer kode å parse og mer kompliserte konsepter som ligger til grunn. Men husk at hastighet er i mange tilfeller mindre viktig enn hvor enkelt det går an å vedlikeholde koden. Du kan spare mye på å obfuskere koden, men det betyr ikke at det er lurt.

 

Men kan vi vennligst komme tilbake til saken?

[Ernie]

Denne artikkelen er skrevet for over fem (snart seks) år siden. I år 2000 eksisterte ikke PHP5 (den første betaen kom i slutten av 2003), og PHP4 er som kjent veldig dårlig til OOP-bisniss. PHP5 har mye bedre støtte for OOP enn PHP4, og har ikke lenger så store forskjeller i fart og effektivitet.

5595099[/snapback]

Kan du vise til tester som backer opp det?

http://www.webmasterstop.com/56.html

Dette er såvidt jeg veit testet med php4. Tilsvarende tester hos meg lokalt med php5 tilsier at man i case1 nå har 439% (486%) og 252% (288%), og for case2 529% (635%) og 172% (208%). Tallene i parentes er det de fikk i php4. Mulig det bare er meg, men det er jaggu meg ikke mye mer effektivitet å se ...

Endret 12. februar 2006 av Ernie

[jorgis]

Denne artikkelen er skrevet for over fem (snart seks) år siden. I år 2000 eksisterte ikke PHP5 (den første betaen kom i slutten av 2003), og PHP4 er som kjent veldig dårlig til OOP-bisniss. PHP5 har mye bedre støtte for OOP enn PHP4, og har ikke lenger så store forskjeller i fart og effektivitet.

5595099[/snapback]

Kan du vise til tester som backer opp det?

http://www.webmasterstop.com/56.html

Dette er såvidt jeg veit testet med php4. Tilsvarende tester hos meg lokalt med php5 tilsier at man i case1 nå har 439% (486%) og 252% (288%), og for case2 529% (635%) og 172% (208%). Tallene i parentes er det de fikk i php4. Mulig det bare er meg, men det er jaggu meg ikke mye mer effektivitet å se ...

5595511[/snapback]

 

Den testen der er dårlig skrevet, og er veldig fokusert på å bevise hvor dårlig OOP er, ved å gjøre det så tungvindt som mulig:

 

class test
{

     function one() {
           return 1;
     }

}

for ($i=0; $i<1000000; $i++)
{

     $testclass=new test();
     $cnt+=$testclass->one();

}

 

Her starter han et nytt objekt hvor hver gjennomgang av for-løkken, istedenfor å flytte den utenfor, slik enhver programmerer med omløp i hodet ville gjort. Gjør et nytt forsøk hvor du flytter $testclass = new test() utenfor for-løkken, og si hva du finner.

 

Når man initialiserer et nytt objekt for hver gjennomgang tilsvarer det å ta med funksjonsdeklasjonen for hver gjennomgang av løkken i "non-OOP"-eksempelet hans, noe som er temmelig absurd å gjøre.

 

EDIT: Har kjørt noen egne tester nå. Jeg har brukt en versjon av hans OOP-test som har flyttet objektinitialiseringen utenfor for-løkken, og resultatene er ganske annerledes:

 

OOP: 7.83 sekunder

Prosedyrell: 5.57 sekunder

Plain: 2.73 sekunder

 

Forskjellen mellom OOP og prosedyrell versjon er da plutselig redusert til 140% (fra 288%), og forskjellen mellom OOP og plain versjon er redusert fra 486% til 286%. Dette er kun forholdet mellom mine målinger og artikkelforfatter sine, og sammenligner ikke PHP4 og PHP5, da jeg ikke orker å installere PHP4 over PHP5 på serveren min i øyeblikket. Om noen andre har anledning til å teste forskjellene med et seriøst test-case hadde det vært flott.

 

Btw: Det ser ut til at forskjellen mellom OOP og prosedyrell versjon tilsvarer forskjellen mellom prosedyrell versjon og plain versjon. Er det da en tøffere "look" om du istedenfor å bruke funksjoner bare copy'n'paster koden rett inn der du ellers ville hatt et funksjonskall? På samme måten: er det tøffere "look" om du lager deg en klasse for databaseoperasjoner el.l. enn å lage filer med bare funksjoner i? Det er en kobling der et sted...

Endret 12. februar 2006 av jorgis

[Ernie]

Hvis du mener det skal være et seriøst case så kan du iallfall ikke plassere opprettelsen av objektet utenfor for-loopen. Når opprettet man sist et objekt og kjørte 100.000 ganger noen funksjoner i den?

 

Det å opprette et objekt og så kjøre 1 eller 10 funksjoner i den er derimot mye mer reelt og tilsvarer bruken de fleste har. At man må loope det 100.000 og 10.000 ganger er bare for å få opp tallene og dermed også nøyaktigheten. Caset er opprettelse av objektet og kjøring av en funksjon en gang, og opprettelse av objektet og kjøring av en funksjon 10 ganger. Ikke opprettelse av objektet og kjøring av en funksjon 100.000 ganger.

Endret 13. februar 2006 av Ernie