Nu er jeg ikke PHP ekspert så følgende bliver baseret på generel OOP.

Fordele ved OOP:

* klasser med både data og funktionalitet afspejler meget godt
  virkeligheden og de fleste programmer skal modellere noget fra
  virkeligheden

* de gængse features i klasser: restriktion af adgang til fields/methods
  med private/protected/public, arv mellem klasser, virtuelle metoder
  og polymorfisme gør det muligt at lave noget meget robust kode og
  noget meget genbrugeligt kode

  [hvad understøtter PHP af dette ??]

* disse ting og diverse andre gør at man normalt antager at OOP sparer
  tid ved større programmer - hvor grænsen går kan diskuteres - jeg vil
  typisk sætte den ved omkring 5000 linier (men det er baseret på C versus C++)

Mange mener at OOP er klasser eller at OOP er arv.

Der skal mere end klasser til for at det er OOP.

Og arv er en meget lille del af OOP som skal anvendes med fornuft.

Nogle alternative definitioner:

OOP er programmering hvor man forsøger at mappe virkelighedens objekt typer
til klasser.

OOP er programmering med brug af konstruktioner som GoF patterns og lignende.

OOP er if og switch fri programmering.

* nr. 1) Da PHP er et scriptsprog og er bygget op som det er, kan jeg stadig ikke se hvad funktioner i en klasse og variabler i en klasse kan, som alm. funktioner og variabler ikke kan.

* nr. 2) Hvad er fordelene ved restriktion?
hvad "kan" arv?

Så det vil sige at man egentlig sagtens kan klare sig uden at programmere OO? Det er bare en "service" for overskueligheder og tilgangen til funktionerne?

www.php.net/oop

alister_crowley -> Jeg ved godt hvad klasser er og hvordan man tilgår og bruger dem. Jeg er interesseret i at finde ud af hvorfor der er fordel i det :)

i PHP er alting public, dog kan man godt lave private methoder, hvis man definere dem inden i en klasse, i så fald skal klasses kaldes før men kan bruge den metode.

Dog er PHP5 på dette punkt langt bedre.
Men hvis grænsen går på 5000 linjer, så skal ens systemer være meget store, før det kan betale sig at kode OOP.

Men at kode overskuelige methoder, og lave klasse til besteme formål er jo smart.

F.eks. lavede jeg til et cs-clan system

bruger.class
nyhed.class
tagwall.class
server.class

Som indenholder alle funktioner, også administrative.
Og så kræver det kun få linjer kode at aktivere dem.

re 1)

Ingenting. Du kan heller ikke noget i PHP som du ikke kan skrive i assembler kode.

Det er bare et spørgsmål om hvad der er den bedste måde at gøre det på -
udviklingsmæssigt og vedligeholdelses mæssigt.

re 2)

Det er en fordel at restricte adgangen fordi det giver en adskillelse mellem
interface og implementation. Hvis du ændrer i interfacet kan du risikere at
skulle skrive en masse kode som bruger din kode om. Hvis du kun ændrer
i implementationen så påvirker du ikke noget. OOP indeholder en lang
række teknikker til at enforce dette d.v.s. at man får fejl hvis man overtræder
spille reglerne. Med procedural kode, så kan man lave konventioner og lave
kode reviews for at checke om konventionerne bliver fulgt. det er ikke nær
så effektivt som et compiler/forolker check.

Arv betyder at en sub klasse arver nogle egenskaber fra en super klasse.

For at adskille interface og implementation (sådan som jeg har forstået det fra Java)
så er du i php nød til at f.eks. lave xml output med php, og så parse det til html med xslt, og så blvier OOP en realitet.

En ven af mig, har lavet patch CMS www.patch.dk
og hvis du læser dokumentationen (http://www.patch.dk/ (...)) så vil du måske kunne se nogle formål med OOP :)

Med få linier kode er den væsentligste grund til at bruge OOP at man lærer det.

Hvordan man strukturerer og genbruger kode bliver kritisk ved store kode
mængder. 100000 linier kode. 1 million linier kode. 10 millioner linie kode.
Når man når derop så kan en 20% forskel i antal linier kode nemt komme
til at betyde en million kroner i forskel i årlig vedligeholdelse.

Jeg har siddet og tænkt lidt over det, men jeg kan stadig ikke se den helt store fordel. Beklager, men i må overbevise noget mere ;o)

Hvis vi nu siger at jeg laver en side som indeholder nogle afstemninger, med klasser. Så bliver det noget lignende:

class Afstemningsmodul {
  function add_new() {
    //...
  }
  function view() {
    //...
  }
  function edit() {
    //...
  }
  function update() {
    //...
  }
}


hvorfor er det så mere smart end at lave det sådan:

function afstemning_add_new() {
  //...
}
function afstemning_view() {
  //...
}
function afstemning_edit() {
  //...
}
function afstemning_update() {
  //...
}

?

I den ene skal man oprette en ny afstemning med
$afstemningsmodul = new Afstemningsmodul;
$afstemningsmodul->add_new();

og i den anden:

afstemning_add_new();

---------------

Ser det ud til at der er noget jeg har misforstået?
Kan en af jer give et eksempel på hvornår classes konkret er være smartere/nemmere end det med alm. functions?

Dit eksempel illusterer hvorfor klasser ikke er nok til at gøre det OOP.

Afstemningsmodul er ikke et objekt i virkeligheden.

Dine klasser vil snarere være:
  Afstemning
  Bruger
  AfstemningsMenu

Ok... Jeg tror måske lige så stille der begnder at gå lys op for mig :-)

Men:

Men hvis jeg så har klasserne
  Afstemning
  Bruger
  AfstemningsMenu

De har hver især nogle funktioner og variabler. Hvorfor skal de kapsles ind i klasser? Jeg tror jeg bliver nød til at bede dig om at skrive/finde et eksempel hvor det er smartere at bruge klasser end alm. funktioner..

Du kan f.eks. lave en abstrakt klasse Afstemning og nogle konkrete klasser
som arver fra den:
  AfstemningJaNej
  AfstemningMangeTal
  AfstemningMangeTekster
hvor
  * Afstemning indeholder det der er fælles for alle afstemninger f.eks.
    titel og kode til at registere at en bruger har stemt
  * AfstemningJaNej indeholder kode til at generere to radiobuttons
    med ja nej og en boolean result
  ...
  * AfstemningMangeTekster indeholder et array af tekster og kode
    til at vise disse med radiobuttons og en integer til result

Koden der læser Afstemning op fra disk vil man så gøre private sådan
at koden der bruger Afstemninger ikke ved hvordan de er gemt. Så kan man
ændre implemenattionen fra at gemme dem som XML filer til at gemme dem
i databasen og være sikker på at det ikke påvirker anden kode, fordi
den funktionalitet er ikke accessable (synlig) fra kode udenfor
klasserne.

Et par links som er PHP relevante:

http://www.phpbuilder.com/ (...)
http://www.phpbuilder.com/ (...)
http://www.liquidpulse.net/ (...)

<ole>

Min egen erfaring er, at OOP begynder at give mening, efterhånden som man arbejder med det - og prøver at vedligeholde OOP'et kode. Det er en anden måde at tænke programmering på - og som Arne påpeger en meget mere virkeligheds baseret måde.

Der er mange fordele ved at indkapsle variabler. Jeg bygger selv en del temmelig store GUI-komponenter i DHTML og der er alene det, at kunne holde variabel-scope'et 'rent' en herlig ting.
Jo flere variabler du skal håndtere, jo mere besynderlige navne får de ofte i alm. procedural programmering - og jo mere uoverskuligt bliver det, hvilke variabler, der hører til, hvor - og skal hvad.
Ved OOP får du flyttet langt de fleste af de globale variabler, du uundgåeligt vil have i procedural kode ind i den kontekst, hvori de hører hjemme.

Når jeg skriver disse komponenter som objekter, kan andre bruge dem og fylde al mulig anden kode ind i samme dokument uden fare for 'interferens'. Objekternes interne struktur - og overordnede relationer - gør det samtidigt let og hurtigt at overskue koden, selvom jeg måske ikke har haft fat i den meget længe.

Selvom JS er prototype baseret og PHP er klasse baseret - og der bl.a. derfor er en del forskelle på den praktiske brug af OOP i de to sprog - er der dog ikke den store forskel, hvad angår de fordele, jeg nævner ovenfor ... eller dem Arne nævner. De er ens for de fleste sprog, der understøtter en form for OOP.

Du er formodentlig allerede vandt til OOP fra alle JavaScript's DOM bindinger. Det er jo ganske praktisk og overskueligt, at image-objektet har en source-property, vi kan læse og sætte. Det gælder også for alle objektets andre metoder.
Metoderne ligger ikke og 'roder rundt' i sproget som løse funktioner, men som metode på objektet, hvor de naturligt hører hjemme.
Det gælder alle HTML-objekterne og prøv f.eks. at forestille dig en r..fuld funktionsnavne, der ville være 'brugt op' allerede.
At dømme udfra JS-kategoriens spørgsmål er der rigeligt med reserverede ord i JS  ;o)

CSS er et eksempel på et formaterings sprog, man i til en vis grad har tillempet OOP-tænkning, hvilket gør det yderst logisk at arbejde med.

OOP er i høj grad en måde at tænke på. Det er min erfaring, at jo mere jeg bruger den, jo mere 'rigtig' føles den  :)

/mvh
</bole>

Et lille eksempel.. du skal udvikle et multiplayer spil. Du laver en SPILLER class, som indeholder alle egenskaber og funktioner som en en spiller kan gøre brug af.

Når en ny bruger joiner spillet, laver du blot en ny instans af klassen, og sætter de egenskaber som kendetegner denne spiller, og så ruller det. Nemt og simpelt.

OOP kan være en rigtig hjælpsom fætter

Eller hvor tit har man ikke selv prøvet at skulle bruge en tæller (som regel $i) for blot at opdage at man har brugt den tidligere, og glemt at unsette den.

Jamen så bruge vi da bare $i2, eller $i3, eller .... og til sidst sidder du og bruger timevis på at bugtracke noget der slet ikke ville være et problem med OOP.

Jeg begynder faktisk at kunne se det smarte i det :) Men som du siger olebole, så føler man det sikkert mere 'rigtigt' jo mere man arbejder med det.. Så det vil jeg da gå i gang med :)

Arne_v -> De links og forklaringer du kom med her til sidtst fik et lys til at gå op for mig ;)

plx -> Yep, det er sådanne eksempler jeg hele tiden har læst. Men jeg har bare stadig lidt svært ved at forestille mig det i PHP.

Men jeg giver det en chance til :) Smid nogle svar.. (Inputs er stadig velkomne..!)

intet til mig ihvertfald, samler ikke på points.

OOP i php er også stadig mærkeligt ;)

svar

Et 'causeri' om personlige OOP-betragtninger under JavaScript, bør vist ikke udløse points her, så jeg springer over  :)