Varför klasser och inte funktioner

Vill man programmera objektorienterat så använder man sig av klasser. Klasser i PHP är inte konstigare än klasser i exempelvis C++.

Av ditt inlägg att dömma så beror din förvirring på att du har koll på funktionsbaserad programmering men inte objektorienterad programmering:
http://en.wikipedia.org/wiki/Object_oriented_programming

Jo, men varför skippa funktioner och gå över till klasser på en hemsida?

greyhound, funktioner och klasser är inte synonymt. Klasser erbjuder mer funktionalitet än så.
Du kan få mer kontroll om du klistrar ihop allting till en klass.
Exempelvis deklarera funktioner och variabler som privata/publika.
Använda konstruktorer som automatiskt gör lite saker när klasserna instansieras.
Sen kan du även sätta egenskaper på dina klasser som kan användas för att påverka hur klassens funktioner fungerar.
Jag håller precis själv på att upptäcka objektorienteringens fördelar. :e

Det "enda" som skiljer en webb-applikation från en "vanlig" applikation är presentations-lagret så varför inte? Innan jag förstod OOP-paradigmet så ställde jag liknande frågor. Funktionsorienterad VS objektorienterat är inte en fråga man kan besvara med ett fåtal rader! Jag tror dock detta svar kan vara till hjälp:
http://answers.google.com/answers/threadview?id=207071

För att förstå fördelarna med det objektorienterad programmering så måste man först förstå det objektorienterade programmeringsparadigmet. Egentligen är inte PHP det bästa språket att använda när man ska lära sig objektorienterad programmering då PHP har en ofullständig OOP-modell och inte är ett rent OOP-språk.

Sun har en ganska bra beskrivning om OOP-koncepten här:
http://java.sun.com/docs/books/tutorial/java/concepts/

Troxy skrev:

Jag håller precis själv på att upptäcka objektorienteringens fördelar. :e

Kul :) Kom ihåg att se en klass som en ritning för att skapa objekt!

greyhound skrev:

Men jag undrar varför man ska arbeta med klasser istället för funktioner, i ett C++ program eller så förstår jag klasser och tycker det är bra. I en php-fil som är till för en hemsida ser jag bara inte poängen.

I klassisk PHP finns det knappt någon anledning att OOP:a, bortsett möjligen från att slå in exempelvis databasåtkomst i ett någorlunda uniformt paket. Kör man så stora grejer att OOP blir viktigt är det ingen bra idé att köra PHP.

Problemet med PHP är inte att språket inte är "rent objektorienterat" (eftersom inga språk som används i någon större utsträckning idag är det), utan att själva ramverket är filbaserat snarare än objektorienterat. I PHP har du din scriptfil och sen körs den igenom uppifrån och ner när nån kommer in på den. I ett objektorienterat ramverk knyter du en "sida" (ett ytterst vagt begrepp i det här sammanhanget) till en klass, eller en metod i en klass. Struts 2 är ett bra exempel på hur ett objektorienterat ramverk kan se ut.

Sen vill jag också påminna om att lösa funktioner inte är dåliga i sig. Det finns massor av fall där det är vettigare att ha lösa funktioner än en "public static" metod i någon klass som ändå aldrig instansieras.

Det finns ju objektorienterade ramverk för php också. Ex. CakePHP och PHPonTrax, varför skulle php vara oävet att bygga enligt den modellen?

colione skrev:

Det finns ju objektorienterade ramverk för php också. Ex. CakePHP och PHPonTrax, varför skulle php vara oävet att bygga enligt den modellen?

Ska man köra stenhårt på objektorienterad programmering och kunna utnyttja paradigmet fullt ut så krävs det att programmeringsspråket har 100-procentigt OO-stöd, PHP är inte ens nära även om det blivit bättre. CakePHP och PHPonTrax ändrar inte detta faktumet (PHPs oo-modell) utan är endast ett framework för att underlätta utveckling i PHP. Visst kan man ändå köra på OO-spåret med PHP, men man bör vara medveten att man långt ifrån kommer kunna utnyttja OOPs alla fördelar.

Compusa skrev:

Ska man köra stenhårt på objektorienterad programmering och kunna utnyttja paradigmet fullt ut så krävs det att programmeringsspråket har 100-procentigt OO-stöd, PHP är inte ens nära även om det blivit bättre. CakePHP och PHPonTrax ändrar inte detta faktumet (PHPs oo-modell) utan är endast ett framework för att underlätta utveckling i PHP. Visst kan man ändå köra på OO-spåret med PHP, men man bör vara medveten att man långt ifrån kommer kunna utnyttja OOPs alla fördelar.

Tack för svar. Jag vet att PHPs objektmodell inte är fullt så bra. Men dit jag vill komma är egentligen om det är skäl nog att inte jobba enligt OO, då det - även inom php - har fördelar.

colione skrev:

Det finns ju objektorienterade ramverk för php också. Ex. CakePHP och PHPonTrax, varför skulle php vara oävet att bygga enligt den modellen?

Med PHP menade jag förstås "klassisk PHP", my bad. Nu tycker jag iofs fortfarande att PHP är en dålig idé för Riktiga Projekt, om inte annat så p.g.a. allt rabalder om säkerheten.

Compusa skrev:

Ska man köra stenhårt på objektorienterad programmering och kunna utnyttja paradigmet fullt ut så krävs det att programmeringsspråket har 100-procentigt OO-stöd, PHP är inte ens nära även om det blivit bättre. CakePHP och PHPonTrax ändrar inte detta faktumet (PHPs oo-modell) utan är endast ett framework för att underlätta utveckling i PHP. Visst kan man ändå köra på OO-spåret med PHP, men man bör vara medveten att man långt ifrån kommer kunna utnyttja OOPs alla fördelar.

Fast det argumentet håller inte heller riktigt. Java och C# är inte heller riktiga OO-språk, och det går alldeles utmärkt att utveckla objektorienterat med dem. Skulle man bara använda puritanska OO-språk vore man tvungen att gå över till typ Smalltalk.

spango skrev:

Fast det argumentet håller inte heller riktigt. Java och C# är inte heller riktiga OO-språk, och det går alldeles utmärkt att utveckla objektorienterat med dem. Skulle man bara använda puritanska OO-språk vore man tvungen att gå över till typ Smalltalk.

Det har du rätt i. Java har ju exempelvis primitiva typer. Min omformulering blir därför att om man vill använda sig av OOP så är det en fördel att använda ett programmeringspråk som är designat för det från början.

Compusa skrev:

Min omformulering blir därför att om man vill använda sig av OOP så är det en fördel att använda ett programmeringspråk som är designat för från början.

Den skriver jag under på (y) Metaforen "rund kloss i fyrkantigt hål" känns aktuell ;)

Mer eller mindre, inte antingen eller

greyhound skrev:

Jag har suttit och surfat runt lite här och var och läst om klasser.
Men jag undrar varför man ska arbeta med klasser istället för funktioner, i ett C++ program eller så förstår jag klasser och tycker det är bra. I en php-fil som är till för en hemsida ser jag bara inte poängen.

Jag tänkte lära mig att jobba med klasser för ut lära mig lite nytt, men det skulle vara kul att veta varför klasser och inte funktioner?

Mitt svar på din fråga är att det inte handlar om antingen eller. Det finns ett antal frågor att svara på, typ:

1. Skall din kod vara återanvändningsbar eller bara en "quick and dirty" snabblösning?

2. Skall din kod fungera väl tillsammans med andras? Då behöver du exempelvis undvika globala variabler, emulera namnrymder för dina funktioner och konstanter, etc.

3. Skall din kod fungera fungera PHP 4 (varför!?!?) så är objektestödet där ingen trevlig bekantskap, eftersom där saknas så basala saker som PPP (Public, private, protected), etc.

4. Skall din kod vara löst "kopplad", så att man kan ändra en detalj utan att riskera regressionsbuggar på andra delar, slippa vara beroende av namngivningskonventioner, etc? "Tight coupling" ses som ett fördärv för professionella projekt.

5. Skall din kod vara testbar? Tendensen just nu är att använda paradigmet "Extreme programming" där man först skriver ett test, sedan koden man skall köra mot testet. Detta i sin tur kräver "lös koppling".

PHP version 5 och framåt har ett bra stöd för objekt. Något sämre än JAVA, som i sin tur är sämre än Smalltalk. Det som saknas i PHP är bl.a.:
- Multipla arv
- "Finally" för try-catch
- Objektöverladdning av enkla typer, såsom strängar, arrayer och hel- och flyttal.

Inget livsnödvändigt!

Jag ser det som en glidande skala mellan helt procedurell kodning och total OO. Mellanläget kallar jag "objektbaserad" och där hamnar de flesta projekt numera för mig.

OO-mönster som fungerar utmärkt i PHP 5 är enligt min erfarenhet:
- Singleton
- Factory (men inte "abstract factory", men vem tusan behöver det för ett webbprojekt?)
- Registry
- Delegator (skulle kunna göras snyggare)
- Data mapper
- Active Record (som jag själv tycker är på tok för hypat)
- Command
Etc.

Se http://www.phppatterns.com/docs/?idx=design

De allra flesta som kodar procedurellt brukar blanda affärs-, presentations- och data-accesslogik på ett hopplöst sätt. Att böra skilja ut dessa är det viktigaste steg man kan ta så fort man lärt sig språkets grunder.

itpastorn, ditt inlägg är intressant för mig, eftersom jag själv känner att mina projekt ibland slutar i gigantiska "korthus" som jag förtvivlat måste hålla ihop från alla håll och kanter.
Antagligen beror detta på att jag inte använder mig av ett konsekvent designmönster, utan friskt blandar programkod och presentation.
Jag har läst en del om MVC-mönster men vet inte riktigt på vilket sätt man kan implementera detta bäst.
Det finns ju en uppsjö av färdiga lösningar och det är svårt att veta vilka att välja.

Troxy skrev:

Jag har läst en del om MVC-mönster men vet inte riktigt på vilket sätt man kan implementera detta bäst.
Det finns ju en uppsjö av färdiga lösningar och det är svårt att veta vilka att välja.

Mitt råd: Börja skilja på presentationen i form av mallar från resten (MC+V). mallarna inkluderar i sin tur sidhuvud, sidfot, etc, enligt sin egen logik.

En introduktion finns på http://keryx.se/artikel-47

Nästa steg: Procedurella page-controlers. Ett kontrollskript per typ av sida. Lägg data-accessen för sig ("modellen")

Enkel struktur för en page-controler:

1. Hämta gemensamma inställningar, initiera klassbibliotek, etc.
2. Filtrera användardata
3. Hämta/lagra i databas (utnyttja ditt kodbibliotek)
4. Bearbeta svaret - ingen output ännu!
5. Initiera mallen
6. Visa slutresultatet
7. Ev. manuell städning/loggning/felhantering

Nu har du en busenkel M-V-C arkitektur! Inte så avancerad, men en god start.

itpastorn, tack för din inspiration!
Just det där med att bearbeta allting INNAN man börjar spotta ut output är mycket bra och gör att man slipper blanda ihop allting.

Enkla möster räcker nog långt för mig. Jag har ju som sagt klarat mig utan det länge, och PHP är trots allt inte rocket science.
Lite ordning och reda i form av konsekventa möster är bara det jag saknar.

spango skrev:

I klassisk PHP finns det knappt någon anledning att OOP:a, bortsett möjligen från att slå in exempelvis databasåtkomst i ett någorlunda uniformt paket. Kör man så stora grejer att OOP blir viktigt är det ingen bra idé att köra PHP.

Detta argumentet har jag sett så många gånger, eller - argument o argument, påstående.

Vad är just "så stora grejer", facebook? yahoo? Ja, visst finns det applikationstyper där PHP verkligen inte passar, men "så stora grejer"? Yahoo har mest trafik i hela världen o bygger sin platform på Symfony och om några vet vad dem gör så är det ju grabbarna där.

spango skrev:

Problemet med PHP är inte att språket inte är "rent objektorienterat" (eftersom inga språk som används i någon större utsträckning idag är det), utan att själva ramverket är filbaserat snarare än objektorienterat. I PHP har du din scriptfil och sen körs den igenom uppifrån och ner när nån kommer in på den. I ett objektorienterat ramverk knyter du en "sida" (ett ytterst vagt begrepp i det här sammanhanget) till en klass, eller en metod i en klass. Struts 2 är ett bra exempel på hur ett objektorienterat ramverk kan se ut.

Att ta orden "rent objektorienterat" och java som exempel i samma stycke känns, tvetydigt. Det Struts2 gör är en avancerad form av den Routing vi ser i t.ex. Ruby och PHP. Stora delar av Struts2 går att implementera rakt av i PHP utan minsta problem.

spango skrev:

Sen vill jag också påminna om att lösa funktioner inte är dåliga i sig. Det finns massor av fall där det är vettigare att ha lösa funktioner än en "public static" metod i någon klass som ändå aldrig instansieras.

Verkligen, och det är därför det är så skönt att man inte är tvingad att ta till public static i php ;).

Compusa skrev:

Ska man köra stenhårt på objektorienterad programmering och kunna utnyttja paradigmet fullt ut så krävs det att programmeringsspråket har 100-procentigt OO-stöd, PHP är inte ens nära även om det blivit bättre. CakePHP och PHPonTrax ändrar inte detta faktumet (PHPs oo-modell) utan är endast ett framework för att underlätta utveckling i PHP. Visst kan man ändå köra på OO-spåret med PHP, men man bör vara medveten att man långt ifrån kommer kunna utnyttja OOPs alla fördelar.

Ja det finns små saker som saknas i PHPs OO-modell, men av alla dessa saker så är det väll bara korrekt Överlagring jag saknar när jag gör mitt dagliga arbete i PHP - och det går att leva utan i många fall. Mycket av funktionerna är syntax socker ;)

spango skrev:

Med PHP menade jag förstås "klassisk PHP", my bad. Nu tycker jag iofs fortfarande att PHP är en dålig idé för Riktiga Projekt, om inte annat så p.g.a. allt rabalder om säkerheten.

PHP i sig är inte mer osäkert en .NET eller Java - det handlar till stor del om det faktum att instegströskeln till PHP "inte" är hög nog och det resulterar i att det blir mycket hemmasnickrare och liknanade som dras hit och således blir det mer fel och brister i applikationer skrivna i php - det beror inte på språket utan på de utvecklare som jobbar med det. Sen blir det automatiskt fler fel upptäckta i den platform som är störst, det är en självklarhet. Se t.ex. på Linux vs. Windows - fler människor försöker ha sönder windows eftersom det är störst och således kan man påverka fler människor med de upptäckter man gör. Det är nackdelen med att vara störst helt enkelt.

Och som jag tidigare "Riktiga Project", Yahoo - världens absolut största site (legat #1 på top1000 listan i tre-fyra år nu) använder PHP+Symfony. Det Argumentet fungerade år 2000 när php4 precis släpptes, nu är det sju år senare och vi som har varit med hela vägen har sett hur extremt mycket php har utvecklats.

itpastorn skrev:

- Multipla arv

Multipla arv finns inte i Java vad jag vet, nu var det nog två år sedan jag gjort något serriöst i java men det ska inte ha ändrats vad jag vet? Samt att i 99 av 100 fall är multipla arv mer ett problem än en tillgång.

itpastorn skrev:

- "Finally" för try-catch

Detta saknar jag, men det går att emulera om man _verkligen_ behöver det och det är mer syntax socker.

Utöver det så min nog min slutpoäng denna: Det gäller att välja rätt verktyg för rätt jobb, men PHP passar för 99 av 100 webbjobb.

Edit: Ursäkta för min totala oförmåga att stava, är helt söndersliten efter att ha jobbat för mycket och ska gå o sova nu, godnatt :).

thr skrev:

PHP i sig är inte mer osäkert en .NET eller Java

Kollar du på antalet security advisories för PHP-motorn framkommer en annan bild. Motorn har dragits med många säkerhetsluckor, och utvecklarteamet verkar ha gjort en halvdan insats för att stampa ut felen.

Antalet publicerade "security advisories" är inget mått sålänge inte alla publiceras på alla platformar.

spango skrev:

Kollar du på antalet security advisories för PHP-motorn framkommer en annan bild. Motorn har dragits med många säkerhetsluckor, och utvecklarteamet verkar ha gjort en halvdan insats för att stampa ut felen.

99 % av alla säkerhetsluckor som PHP drabbbats av ligger inte i PHP-motorn utan i dåliga PHP-applikationer, beroende på att det finns så många nybörjare och så många dåliga nybörjarguider. (Jag säger bara - med en rysning - "Jesper Ek"...)

Lysna in detta: http://devzone.zend.com/article/2159-PHP-Abstract-Podcast-Episode-3-PHP-Security-Compared-to-Other-Development-Environments