Enkel tumregel:om en klass extends
en annan, då är den klassen är den föräldraklassen (endast något ändrad eller utökad). Du kan klara den här barnklassen istället för föräldraklassen. Exempel:
class Foo { }
class Bar extends Foo { }
function baz(Foo $foo) { }
baz(new Bar);
Detta fungerar, baz()
förväntar sig en Foo
men accepterar också en Bar
, eftersom Bar
är en Foo
.
Nu är dina Users
en Database
? Nej. Dina användare är inte en databas. Dina användare använder en databas. Om ens alls bör du använda komposition :
class User {
protected $database;
public function __construct(Database $database) {
$this->database = $database;
}
}
En klass ska vara vad dess ansvar är . Ansvaret för en användarhanteringsklass är att hantera användardata. En del av det kan involvera att prata med en databas, men det betyder inte att användarhanteringsklassen är en databas. Om User extends Database
, det betyder att den kan göra allt i Database
klass kan göra (och mer). Det betyder att du kan använda Users
klass överallt istället för Database
klass, och det är ingen mening. Håll ansvarsområden åtskilda.
Nu är det fortfarande diskutabelt om det är rätt struktur eller inte, men det går åt rätt håll. Men du kanske verkligen vill ha en Users
klass, som representerar en användare . Du har då en UserManager
eller UserORM
eller UserStorage
eller vad som helst, som handlar om att hämta och lagra Users
objekt i en databas. Den här klassen använder i sin tur en Database
att göra just det. Det håller ansvaret tydligt och separerat. Users
klass representerar användardata, Database
klass interagerar med databasen, UserORM/Manager/whatever
i mitten förhandlar mellan de två.