OOP for begyndere

Ideen er, med ovenstående kode, at man så opretter en nyhed med:

<?
    $nyhed = new News();
    $nyhed->setHeader($_POST['header']);
    $nyhed->setAuthort($_POST['author']);
    $nyhed->setPicture($_POST['picture']);
    $nyhed->setText($_POST['text']);
    $nyhed->add();
?>

Fortæl mig hvis jeg er helt galt på den!

Jeg er ikke specielt vant til at arbejde med objekter, men lige nu ser det mest ud til at du laver det objektorienteret bare for at gøre det, og ikke fordi du har en ide om hvad fordelen skulle være.

Hvis der skal være mening i det, kan du for eksempel lave validering af indholdet i dine metoder, så de returnerer en fejl, hvis man forsøger at sætte noget forkert ind.

Derudover bør du også kontrollere, at der er meningsfyldt indhold i variablerne inden du kalder databasen.

Og et MySQL-tip: brug MySQLs indbyggede NOW()-funktion til at indsætte tidspunktet med mindre det skal kunne ændres af dit objekt. Hvis det skal kunne ændres, så brug et normalt timestamp på PHP-siden og brug MySQL-funktionerne FROM_UNIXTIME() og UNIX_TIMESTAMP() i din SQL til at konvertere mellem de to typer.

jeg er ikke selv 100% stiv i OOP, men efter hvad jeg kan se så ser det fint ud, jeg tror godt du kunne lave date sådan her, men at have den med som constructor er vel også ok:

var $date = date("Y-m-d H:i:s");

når jeg skriver en funktion laver jeg gerne et indryk sådan her:

function setHeader($var) {
  $this->header = '$var';
}

så synes jeg koden er nemmere at læse senere hen - tja det var hvad jeg lige kunne finde på ;o)

sandbox>> hvorfor egenlig UNIX? - kunne man ikke bare benytte TIMESTAMP som MySQL indeholder?

BTW: så er jeg enig med sandbox om at NOW(); er smartest at bruge

TIMESTAMP i MySQL er en kolonnetype. Bortset fra at MySQL selv autoopdaterer feltet nogle gange, så er det magen til DATETIME-typen, som er den normalt anbefalede type til dato+tid-værdier.

En MySQL DATETIMEs indhold er ikke umiddelbart forståeligt for PHP, så det skal konverteres, hvis PHP skal kunne arbejde med det.

PHPs eget dato+tid-format er tilgengæld ikke umiddelbart forståeligt for MySQL, så hvis man skal kunne behandle det i en forespørgsel, skal det konverteres til en MySQL DATETIME.

MySQL kan selv lave begge de to konverteringer. Det gøres med de to funktioner, jeg nævnte. Årsagen til at de hedder noget med UNIX er den simple, at PHPs interne datoformat er det samme som Unix's interne datoformat.

Der er ikke som sådan noget i vejen for at gemme en PHP tidsvariabel direkte i MySQL som en INT, men det vil gøre det besværligt (hvis ikke umuligt) at lave avanceret datosøgning, som f.eks. find alle artikler, som er skrevet i december måned uanset år.

Det, som denne kode gør er, at lave datoen i et passende format til MySQL DATETIME i selve PHP-koden. Grunden til at jeg ville foretrække at flytte det over i SQL-koden er, at så behøver det omkringliggende PHP-kode ikke tage hensyn til, at det skal ind i MySQL bagefter, men kan bare behandle det som enhver anden variabel med et tidsstempel.

tak for den forklaring ;o)

Kan nogen komme med gode ideer om hvornår det kan være bedst at bruge klasser?

Klasser og objekter er en måde at tænke på. Imperativ programmering er en anden. Jeg kan ikke se at der er nogen problem med din klasse - også selvom den er lille.

Jeg bruger næsten ren OO-programmering i min kode og syntes selv det giver en bedre kode.

Jeg har også fået fornemmelsen af, at OOP giver en "renere" kode og et større overblik. Det er nok også mest derfor jeg er begyndt at lære det. Min kode har nemlig tendens til at blive ret rodet, så jeg håber det vil gøre det nemmere at programmere...

Men OOP er jo ikke noget man bare lige lærer :)

dennismp: er der nogle gode sites eller bøger du kan henvise til, omring OOP?

Ikke umiddelbart. Jeg har lært OO igennem C++ og Java, så det kan jeg ikke hjælpe dig med.

Jeg vil give dennismp ret i, at det for en stor grad handler om måden man tænker på sine programmer og datastrukturer på.

Det, jeg ser som den store fordel ved OO i modsætning til funktionsbaserede programmer er, at med OO er det tydeligt hvilke metoder (eller funktioner), der hører sammen med hvilke variable. Det gør det altså lettere at have flere funktioner, der samarbejder om en bunke data uden at variablerne behøver være globale eller på anden måde tilgængelige for programmet udenfor.

Jeg kan anbefale denne bog, som lærer dig at tænke objektorienteret. Ikke bare at skrive objektorienteret kode.
Du skal lære at tænke OO for at kunne udnytte OOP.
I øvrigt er OOP godt i store projekter, hvor mange skriver på de samme programmer. Man skal også passe på ikke at bruge OOP bare for at bruge det. Det er der nemlig ikke nogen fordel ved. Yderligere skulle OOP være så fantastisk fordi det er muligt at genbruge klasser - MEN det kræver jo at man tænkte OO da man skrev klassen!!!
Nå, men omtalte bog er kanon. Jeg brugte den selv til at få styr på OOP. Der er ikke så meget kode i den, og det der findes er java. Jeg kan ikke selv programmere java, men det er heller ikke nogen forudsætning, da det jo ikke er en java-bog!

19.651
Weisfeld, Matt
Objektorienterede begreber / Matt Weisfeld ; oversættelse: Peter Hauge Jensen. - 1. udgave. - Valby : IDG, 2001. - 223 sider : ill.

Originaltitel: The object-oriented thought process.
Indhold: Introduktion til objektorienterede begreber ; Tænk objektorienteret ; Avancerede objektorienterede begreber ; Opbygning af en klasse ; Retningslinjer for design af klasser ; Objektorienteret design : udviklingsprocessen ; Nedarvning og komposition ; Frameworks og genbrug ; At bygge objekter ; Et overblik over UML ; Udviklingen af objektorienterede sprog.
Med litteraturhenvisninger.
ISBN 87-7843-451-3 : hf. : kr. 249,00.

Tit og ofte er det altså smartest at bruge ganske almindelige funktioner i php, hvis man kun har sin egen lille private hjemmeside!

Læste et sted, at OOP ikke henvender sig til projekter på under 10.000 linier kode. Det udsagn skal nok tages med et gran salt, men lad være med at lave din kode OOP, hvis det er mere overskueligt for dig selv blot at have en funktion!

muddi: Jeg tror du har ret... det jeg sidder og laver nu kommer aldrig op i den størrelsesorden. Jeg har bestilt den ovenstående bog, den lyder perfekt.

Jeg lukker spørgsmålet, så den der først lægger et svar får point...

Først! ;)

sådan

sådan

Tak for point Baronen :)

Muddi: Det er da noget sludder du skriver. :)

Self. kan man lave ubrugeligt OO kode - det kan man jo ved alle sprog. For at programmere OO, skal man jo tænke i OO ellers giver det da ikke mening. Bare fordi man koder i java, behøver man jo ikke at lave OO-kode. I princippet kan man jo også forsøge sig med OO-programmering i et ikke-oo sprog, men det gør det bare mere besværligt, hvilket går ud over læsbarheden mv. OO-sprog, understøtter bare tankegangen om OO. Det er stadig programmøren der skal skrive koden.

Jeg har da masser af eksempler på at OO sagents virker fint til projekter under 10.000 linjers koder. Jeg har et php library på 500 som ville være langt mere besværligt med "alm." programmering.

"Man skal også passe på ikke at bruge OOP bare for at bruge det. Det er der nemlig ikke nogen fordel ved."

Øh? Jeg bruger da lige præcis OO, da det giver en fordel.

Kvaliteten af din kode afhænger stadig af din evner som programmør. OO giver dig lov til at bruge et højere abstraktionsniveau. Koder du stadig som du gjorde da du arbejdede i assembler, så hjælper det dig ikke.

Ja, jeg er glad for OO. Det overhead der giver, tjener sig normalt ind igen, imho.

dennismp >> efter at have læst dit indlæg tror jeg vi er ret enige. Det med 10.000 linier skrev jeg at man skulle tage med et gran salt, da jeg ikke kan huske min kilde, og derfor ikke kan bekræfte rigtigheden af.
Men har jeg ikke ret i, at det i store projekter med mange programmører der har hænderne i fadet, er en fordel at bruge OOP?

Jeg bruger selv OO-php til ganske små projekter. Jeg har klasser der ikke er på mere end 40-50 linier, men det har ikke været for at kode objektorienteret.
Jeg ved at man kan kode de samme ting hvadenten man bruger den ene måde eller den anden. Forskellen er blot hvordan man kommer frem til resultatet.

"Man skal også passe på ikke at bruge OOP bare for at bruge det. Det er der nemlig ikke nogen fordel ved."

Der fik jeg ikke udtrykt mig spor tydeligt kan jeg godt se, men jeg mener noget i retning af, at man skal få en forståelse af OO inden man roder for meget af sin kode ind i OO begreber.

Jeg ved ikke om jeg fik gjort mit udsagn tydeligere med dette indlæg?
Men når jeg læser dit indlæg er jeg sådan set enig.

Morten :o)