OOP med PHP?

Det kommer an på hvad din brugerklasse skal.

Hvis din brugerklasse specifikt handler om databaseintegration med dine brugere, og at alle eller næsten alle operationer med brugerklassen skal igennem databasen, så giver det mening hvis den arver databaseklassen.

Hvis brugerklassen derimod også skal lave ting der ikke er fra databasen, på lige fod med database-operationerne (fx hvis den både skal håndtere database-operationer og session-data om den nuværende bruger), så giver det bedre mening at den kalder metoder fra databaseklassen snarere end at nedarve den, og det samme hvis du bruger en eventuel session-/cookie-klasse.

principielt bør man som klasse vel arve fra de klasser man skal bruge... men gælder det også i klasser der ikke umiddelbart ligner hinanden i brug/funktion?

kan man iøvrigt ikke kun arve fra en klasse i php?

#0 Du kan kigge på hvordan flow3 eller doctrine håndterer database abstraktion.

Nej det er noget pjat det der! Du skal ikke nedarve en klasse bare fordi du skal bruge den ... og slet ikke saadan som det bliver beskrevet her.

Derudover vil det jo betyde at du har en ny forbindelse til databasen hvergang du haandterer et database-objekt. F.eks. hvis du har et objekt til at haandtere brugere og et andet til at haandtere gaestebogsindlaeg med saa vil de have hver sin forbindelse til databasen ... det giver problemer.

Den rigtige maade at goere det paa er noget ala:

class Database()
{

// Stuph
}

class Brugere()
{
private $db;

public function __construct($db)
{
$this->$db=$db;
}
}

$db = new Database();

$bruger = new Brugere($db);


Haaber du fangede ideen i det ... det er saadan man goer hvis det skal goeres rigtigt :)

Som udgangspunkt så skal vi lige slå et *helt* basalt OOD koncept fast:
"Favour composition over inheritance".

Altså, undgå at nedarve som udgangspunkt med mindre du vitterligt kan forsvare det. I mange tilfælde vil komposition (det at instantiere en klasse som en lokal variabel inde i sig selv) eller aggregering (at benytte en instans af en klasse som er instantieret andetsteds) give lige så meget mening.

Dette råd giver specielt mening såfremt man snakker om single-inheritance sprog så som Java/C# - muligvis PHP, jeg er for doven til at slå det op.
(Basalt set, kan du kun arve fra én klasse og eventuelt implementere et antal interfaces, så har du med et single-inheritance sprog at gøre).

Hvorfor ? Well, igen, hvis det er et single-inheritance sprog så har du ikke opbrugt din ene værdifulde mulighed fra at arve fra en klasse, endvidere har du med komposition bedre kontrol over din klasses interface.
Såfremt du arver kan du ALDRIG indskrænke interfacet (dvs. skifte en public metod til private) - kun udvide det.
Derfor kan andre nu benytte din klasse og kalde metoder som du måske ikke ønsker de skal kalde direkte.
Ergo har du ødelagt indkapslingen af din kode - hvilket er fy-fy :)

Nope :) Men har haft 2 andre kurser på ITU i KBH som har fokuseret dels på OO softwarekonstruktion, dels på design, patterns og principper (samt self UML etc).

Derfor ;)