Gå til innhold

OO - generelle spørsmål


Anbefalte innlegg

Har kodet en del PHP tidligere, samt en del C++. Kjenner altså til både PHP og OO ganske greit, men sliter litt med å komme i gang med kombinasjonen av de to..

 

Hvis man f.eks. tar for seg en gjestebok. Hva vil da typisk være klassene? Vil man ha en klasse "innlegg"? Med "Header", "Tekst" og "Navn"? I så fall blir det jo bare å putte rett fra databasen inn til masse instanser av den klassen...

 

Eller vil man bare ha en "gjestebok"-klasse, men en del nyttige funksjoner? "print_alle_innlegg", "slett_innlegg" osv. Kanskje en db-kobling som variabel?

 

Som dere skjønner, noen tips til generell oppbygging av gjestebok el. hadde vært fint :)

Lenke til kommentar
Videoannonse
Annonse

En klasse er en mal for et objekt. Et objekt er en instans av en slik mal. Alt som "er noe" kan være et objekt av noe. Se på det sånn da. Gjesteboken din er en ting, som er fylt med andre ting, som er innlegg. Så hva med en klasse for gjesteboka, som inneholder mange objekter av typen "innlegg"?

 

Meeen, så er ikke PHP mitt store felt akkurat :p

Lenke til kommentar

Hva er det egentlig du sliter med PHP kontra C++? De er jo egentlig ganske sammenlignbare. Lag de samme klassene i PHP som du ville laget i C++. Litt avhengig av hvor komplisert gjestebok du vil ha, men du bør vel i alle fall ha minst 2 klasser, GuestBook og Post. Person om du har registrerte brukere, potensielt en Guest klasse for uregistrerte brukere. Det er ingen regel som sier at du må ha funksjoner på en klasse forøvrig. Det er helt greit å samle ting som naturlig hører sammen i en klasse og sende instanser av denne rundt i koden.

 

Edit: Det er forøvrig ingen gode grunner til å ha norske navn på klasser og variabler :)

Endret av The Jackal
Lenke til kommentar

Det første man må lære med OOP, er at det ikke tilbyr noe rent praktisk. Det kan føles som mye unødvendig arbeid forsi man lett kan gjøre ting på andre måter med mindre kode. Men poengetl igger i å lage abstraksjoner.

 

Uten OOP ville du kanskje hentet ut innlegg fra databasen manuelt med å skrive spørringer mot databasen; noe som er lavt i avstraksjonsnivå. Men i stede lager man en "Gjestebok"-klasse, denne holder så alle innleggene - hvor man kan hente de ut og legge til nye.

 

Man kan da bare gjøre enkle ting som:

Gjestebok->skriv(kommentar);

 

Dette er da lett forstålig kode, og siden man ikke trenger å se alt som skjer i bakgrunnen så ser man lett at denne delen av koden laget et nytt innlegg i gjesteboka.

Lenke til kommentar

En grei måte å komme i gang med OOP for PHP er å bruke CodeIgniter. Da slår man flere fluer i en smekk - OOP, MVC, DRY, etc. En god grunnstruktur som allerede er objektorientert.

 

http://codeigniter.com/

 

Edit: Det er forøvrig ingen gode grunner til å ha norske navn på klasser og variabler :)

Det er ikke sant. Enkelte lærere vil ha norske navn!

 

Da bør du be de lærerne å komme seg ut in the real world :)

Lenke til kommentar

Ettersom PHP ikke har støtte for Unicode er det ikke noen god idé å bruke norsk.

Det jeg mener er at hvis en først skal bruke norsk, bruk æ, ø og å også, ellers får man helt forferdelig uleselige variabelnavn, som blaabaersyltetoey. Men ettersom PHP ikke støtter Unicode på noen som helst måte kan, og vil, dette skape problemer.

 

Nok et punkt på hvorfor PHP er et rævva programmeringsspråk.

  • Liker 1
Lenke til kommentar

Ettersom PHP ikke har støtte for Unicode er det ikke noen god idé å bruke norsk.

Det jeg mener er at hvis en først skal bruke norsk, bruk æ, ø og å også, ellers får man helt forferdelig uleselige variabelnavn, som blaabaersyltetoey. Men ettersom PHP ikke støtter Unicode på noen som helst måte kan, og vil, dette skape problemer.

 

Nok et punkt på hvorfor PHP er et rævva programmeringsspråk.

 

PHP ække et programmeringsspråk! *runs*

Endret av The Jackal
Lenke til kommentar

Njaaa, det var vel å strekke det litt langt... BMP er jo bare et format til å representere og strukturere bilde data i på standarisert måte. BMP gjør noe ingenting. Hvis du mente noe anna en bitmap så må du bare si ifra =)

BMP inneholder instruksjoner for et program for å lese bildedata fra en oktettstrøm. Dette gjør det til et deklerativt programmeringsspråk.

Lenke til kommentar

Njaaa, det var vel å strekke det litt langt... BMP er jo bare et format til å representere og strukturere bilde data i på standarisert måte. BMP gjør noe ingenting. Hvis du mente noe anna en bitmap så må du bare si ifra =)

BMP inneholder instruksjoner for et program for å lese bildedata fra en oktettstrøm. Dette gjør det til et deklerativt programmeringsspråk.

 

Jeg foretrekker å kalle et lite, og low/mid-end språk for et skriptspråk. Vidre så kan det refereres til som et programmeringspråk, et annet punkt jeg bruker basere meg på er at flere skriptspråk kompileres ikke, de blir tolket i øyeblikket de vises. (At de KAN kompileres er en annen sak).

Lenke til kommentar

Den evige scriptespråk VS programmeringsspråk.

 

Jeg personlig ser på scriptespråk som en undergruppe av programmeringsspråk - altså er alle scriptespråk også programmeringsspråk. Det er i hovedsak bruken som definerer om noe er et script eller program - ikke språket.

 

Men dette blir veldig off-topic egentlig, det finnes nok mange tråder man allerede kan diskutere dette i.

  • Liker 1
Lenke til kommentar

Indeed. Dessuten er det en diskusjon som er veldig lite konstruktiv. Det er kun en semantisk diskusjon som ikke har noen som helst interesse utenfor ordbøker.

 

Når det gjelder OOP så er det egentlig ikke noe stort problem å definere en objektorientert struktur. Bare del problemet opp i alle logiske enheter, og du vil da ha en objektorientert struktur. En gjestebok består av selve gjesteboken, innlegg og brukere som skriver i gjesteboken; det er minimum av logiske klasser en også da må lage.

  • Liker 1
Lenke til kommentar

Pkt. 1: Jeg støtter engelsk som språk i kode. Brukte bare norsk i eksemplet tilfeldigvis.

 

Men la oss da si vi har klassen Guestbook som kanskje har variablene name, numberOfPosts,

 

Så har vi klassen Posts, med varibalene Header, Greeting, Name

 

La oss si vi har en index.php, vil den da typisk (vi lager det enkelt her) være:

 

<?php
//some includes
$guestbook = new Guestbook();
switch($action)
{
case 1: //Nytt innlegg fra $_POST
$guestbook->insertNewPost($subject, $greeting, $name);
break;
case 2: //Admin har slettet en post
$guestbook->deletePost($postId)
break;
default:
$guestbook->listAllPosts();
break;
}
$guestbook->printForm();
?>

 

Det er da jeg sliter med å se hva jeg skal med en "Posts"-klasse.. Jeg ville bare latt printAllPosts i Guestbook-klassen hente alle meldingene fra databasen og printet disse...

Lenke til kommentar

Altså når man programmerer objekt-orientert så er meningen at minst alle ting som er en egen ting, skal også være sitt eget objekt og beskrives av en klasse.

 

En post er en ting, derfor skal den være et objekt.

En gjestebok er en ting, derfor skal den være et objekt.

En bruker et en ting, og skal derfor være et objekt.

 

Kan dermed han følgende struktur:

 

<?php
class Guestbook
{
private posts;
public function addPost($post);
public function getAllPosts();
public function deletePost($post);
}

class Post
{
private date_created, date_last_edited;
private user, message;

public function getDateCreated();
public function getDateUpdated();
public function getAuthor();
public function getMessage();
public function setMessage($message);
public function delete();
}

class User
{
private name, signature, avatar;

public function getName();
public function getSignature();
public function setSignature();
public function getAvatar();
public function setSignature();
}
?>

 

Her ser man at man har 3 klasser som samarbeider med hverandre. En gjestebok som inneholder en liste med poster, hvor post-objektet inneholder all infoen om en spesifikk post. Hver post har så også en referanse til et objekt av typen bruker - som har infoen om den bestemte brukeren som skrev posten.

 

Man kan da lage ganske enkel forstålig kode for en gjestebok som blir noe slikt som dette:

 

<?php
$guestbook = new Guestbook();

// Ønsker å legge til en ny post
$user = new User($username, $signature, $password); // username, siangature og avatar er her hentet fra databasen
$post = new Post($user, $_POST['message'], $time_now, null); // user er her objektet over, message blir det brukeren sendte inn.
$guestbook->addPost($post);

// Ønsker å printe ut alle postene i gjesteboka:
$posts = $guestbook->62;getAllPosts();
foreach($posts as $post)
{
$author = $post->getAuthor();
printf("<p>%s - Skrevet av: %s.&</p>", $post->;getMessage(), $author->;getName());
}

?>

 

legg spesielt merke til at alt av SQL-spørringer og slikt er vekk og skjult - da det er gjemt bort i klassene - og når man holder på med koden trenger man ikke lenger å tenke på hva som skjer opp i mot databasen. Koden er og lett å forstå - og man ser lett hva ting faktisk er.

 

I tillegg trenger man heller ikke tenke på detaljer som "id" til ulike poster og slikt - da det håndteres bak kulissene. Vil du slette en post kan du enten gå via guestook->deletePost() og legge den ved som argument - eller man kan bare kalle på delete direkte på posten.

Endret av etse
  • Liker 1
Lenke til kommentar

Tjaaa, jeg er ikke helt enig.

 

Både bruker og innlegg er underordnet Gjestebok-klassen.

 

Tenk om man har mange klasser på en side, f.eks en som heter blogg-post. Da vil jo en egen klasse til gjestebok-post gjør at man ender opp med unødvendig mange klasser.

 

Men dette går mye på smak og behag.

Lenke til kommentar

Jeg er usikker på om det er noe som heter "for mange klasser" for det er ihvertfall en problemstilling jeg aldri har vært borti. Det jeg derimot har vært borti, er for få klasser, og programmer som er helt prosedyrebasert. Dette er kode som er helt forferdelig å vedlikeholde. Jeg jobber som IT konsulent, så hverdagen min er å gå igjennom kode som andre har skrevet. Del opp i klasser og gjør dem så små som mulig.

Jo mindre de er, dess enklere er det å skrive unit-tester. Det er også enklere å få et grovt overblikk over hvordan koden funker.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...