Klasser, metoder, funksjoner, variabler ...

[olafmoriarty]

Jeg skal være helt ærlig: Jeg har aldri brukt klasser i PHP. Jeg var ikke helt klar over at muligheten eksisterte før svært nylig.

Men jeg ser at en rekke API-er, samt eksempelscript her i forumet, bruker klasser, og da begynner jeg selvsagt å tro at dette er noe det kan være verdt å lære. Problemet er at når jeg forsøker å sette meg inn i hva klasser egentlig er for noe, ender jeg opp som et større spørsmålstegn enn før jeg begynte å lese. Joda, sikkert praktisk å kunne, men hva kan jeg egentlig bruke det til?

Jeg etterlyser konkrete eksempler på hva dere bruker klasser til (jada, jeg har lest eksempelet med at man kan ha en klasse som heter bil og så kan hver del av bilen ha en variabel og hver ting bilen kan brukes til en metode og alt det der, men hvilken rolle spiller det for meg når jeg koder PHP?), gjerne med medfølgende forklaring på hvorfor bruk av klasser i det tilfellet er bedre enn vanlige funksjoner/variabler. Lover å være raus med ryktepoeng.

 

[tyr897]

En evig debatt det her. Selv bruker jeg som regel klasser.

I det store og hele kan man si at det er to forskjellige måter å tenke på. Noen liker mora, andre liker dattera.

I PHP kan OOP for eksempel være særdeles nyttig dersom en benytter seg av MVC (Model, View, Controller) i en eller annen form. Jeg går ikke inn på det her, men viser en kort forenklet kodesnutt som bruker en model og et view.

<?php
// vi er inne på en side og skal hente ut en spesifikk artikkel
$Articles = new ModelArticles();
$article = $Articles->fetch( $_GET['id']);

// det kan være at noen har postet en kommentar
$Comments = new ModelComments();

if ($_SERVER['REQUEST_METHOD'] == 'POST') {
   // dette kan kalles en ORM, table row gateway e.l.
   $commentRow = $Comments->createRow();
   $commentRow->populate($_POST);
   $commentRow->save();
}

// vi henter også ut kommentarene
$articleComments = $Comments->fetchAllByArticle( $_GET['id']);

// vi lager et view (i bunn og grunn en php fil, som presenterer dataene - separat fra logikken som nå henter dem ut)
$View = new View("/en/ekstern/fil/som/presenterer/variablene/vi/setter.php");
$View->setLayout("/vi/har/en/layout/fil/vi/bruker/som/inkluderer/view/filen.php");

// kanskje vi kjører utf-8?
$View->setEncoding("utf-8");

// vi gir viewet variabler å presentere
$View->article = $article;
$View->comments = $articleComments;

// viewet kjører og spytter ut fiks ferdig html
$View->display();

Å lage lignende kode med bare bruk av funksjoner vil være adskillig mer tungvint. Ikke bare grupperer man forskjellige funksjoner sammen på en enkel og lettfattelig måte når man bruker objekter, men hva hvis man f.eks. bruker flere views?

 

[Pong]

MVC har i mitt hodet ingenting med OOP å gjøre.
Jeg vet ikke hvordan du skriver dine funksjoner, men hvis ting blir adskillig lettere ved å organisere de som objekt, så er det forbedringspotensiale, tror jeg.

// vi er inne på en side og skal hente ut en spesifikk artikkel - også kommentarene
$artikkel = artikkel_hent($_REQUEST['id']);
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
kommentar_lagre($artikkel,$_REQUEST);
}
$kommentarene = kommentar_hent($artikkel);
// Bruk evt. en template til dette, men det har forsåvidt ikke så mye med saken å gjøre
echo artikkel_format($artikkel,'html');
echo kommentar_format($kommentarer,'html');


Hovedfordelen med oop er for min del en mer oversiktlig navnestruktur - og hvis ting er bygget riktig, en mulighet for å enkelt utvide en applikasjon. Men i praksis (for)fører det til å bygge katedraler fremfor bazaarer.
Uansett.. for å forstå hvilken muligheter jeg har med et objekt, så må jeg fremdeles lese alle metoder (minst funksjonnavnene). Ikke så mye tid å vinne med en situasjon der alle metoder er lagret som funksjoner i en egen php fil (hvis det er gjort riktig).

Med php4 kom også overloading (tror jeg) - og det var ganske bra, men så leste jeg litt om json, og ved å bruke den tankegangen så har jeg jo all fleksibilitet som jeg trenger: altså: i stedenfor for å opprette flere constructors alt etter hvor mange variabler man får inn, så går jeg ut fra 1 variable (array), som inneholder mye eller ikke så mye data.

 

[tyr897]

MVC har i mitt hodet ingenting med OOP å gjøre.

Jeg sier ikke at MVC forutsetter OOP, men jeg vil fastholde at MVC er adskillig enklere med OOP enn en prosedural (av mangel på en bedre oversettelse) fremgangsmåte.

Jeg vet ikke hvordan du skriver dine funksjoner, men hvis ting blir adskillig lettere ved å organisere de som objekt, så er det forbedringspotensiale, tror jeg.

Jeg vil tvert imot våge å presentere den motsatte påstand. Det at du ikke utnytter potensialet i objekter, er ikke ensbetydende med at jeg ikke utnytter mulighetene i vanlig prosedural programmering. Det er dog igjen som jeg sier, at hva som er "enklest" er en personlig preferanse.

Jeg tror ikke function overloading har kommet i php før 5.3 (sammen med namespaces). Hva JSON har med saken å gjøre tror jeg du må utdype litt mer, i tillegg er jo JSON faktisk en objekt notasjon.

Uansett.. for å forstå hvilken muligheter jeg har med et objekt, så må jeg fremdeles lese alle metoder (minst funksjonnavnene). Ikke så mye tid å vinne med en situasjon der alle metoder er lagret som funksjoner i en egen php fil (hvis det er gjort riktig).

Jeg er ikke helt sikker på hva du vil frem til her. Man må jo selvsagt lese dokumentasjon/api reference på funksjoner/klasser/biblioteker man ønsker å benytte.

Med tanke på viewet/templatet/hva man vil kalle det, kan man selvsagt lage noe lignende proseduralt, men du må da passe på å sende rundt viewet du først laget så man vet hvilket view det referes til. Og hvorfor drive å sende rundt en array i forskjellige funksjoner, når man likegodt kan ha et objekt - hvor man kan overloade metoder ved behov?

Dersom ting ikke alltid går i en rett linje ovenfra og ned, forenkles kodingen ved å ha et objekt, fremfor rene funksjoner. Det forenkler også prossesen med å bedrive gjenbruk av tidligere kode, DRY - don't repeat yourself.


Modeller er absolutt enklere i OOP enn proseduralt. ModelArticles vil selvsagt hente de fleste metoder (kanskje til og med alle) fra et foreldreobjekt.

$Articles->fetch() vil med andre ord allerede være definert. articles_fetch() og X antall funksjoner må defineres på nytt, for hver enkelt tabell (selv om de kanskje kaller en mer generell funksjon selv). Man kan isteden bruke model_fetch('articles', $_GET['id']), ikke like intuivt, og hvis man da senere finner ut at man trenger en litt mer avansert fetch-metode (som ville ganske enkelt blitt lagt til i Articles objektet) må koden enten endres flere steder, eller så må model_fetch plutselig ta hensyn til hvilken tabell det refereres til. Slik kan koden vokse seg stor og uoversiktelig, og funksjonene må skrives på nytt for hver enkelt applikasjon man lager.

En godt gjennomtenkt prosedural kode fungerer selvsagt fint. Men man tenker og strukturerer koden anderledes enn en objekt orientert kode, og i mine øyne kan det lett bli en mer rotete og mindre modulær kode.

Poenget er uansett at dette er i meget stor grad smak og behag, men at det finnes situasjoner hvor objekter helt klart vil være å foretrekke - og at man for all kan klare seg fint uten. Det er selvsagt også situasjoner hvor det er helt meningsløst å bruke objekter, som kun vil bidra med å overabstrahere koden.